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inteipreteren  en  prepareren  van  berichten  geformatteenl  volgens  ADatP-3.  Het  uiteindelijke  doel  is  de 
kwaliteit  van  de  berichtgeving  en  berichtenverwerking  te  vergroten. 
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Abstract  (unclassified) 

This  document  outlines  the  results  of  a  research  project  (assignment  A91KL645)  on  the  automated 
processing  of  military  messages.  The  project  focussed  on  automated  supjwrt  during  the  drafting  of  outgoing 
and  the  processing  of  incoming  messages  formatted  according  to  ADatP-3.  The  final  goal  is  to  increase  the 
quality  of  the  information  service  by  an  upgrading  of  message  processing  capabilities. 

Within  the  scope  of  this  research  project  an  analysis  was  made  of  the  ADatP-3  message  structure,  the 
message  processing  functionality,  some  existing  message  handling  systems  and  an  automated  message 
handling  system  (AMH)  in  development. 


TNO-rapport 


Pagina 

4 


Samenvatting  voor  het  management 

In  juni  1991  heeft  de  Koninklijke  Landmacht  (KL)  bij  het  FEL-TNO  een  opdracht  geplaatst  om 
onderzoek  te  doen  naar  de  geautomatiseerde  verwerking  van  (NATO)  militairc  berichten.  Dit  om 
de  interoperabiliteit  binnen  de  krijgsmacht  en  tussen  NATO  krijgsmachten/partners  te  verbeteren. 

De  uitwisseling  van  infomiatie  is  een  essentiele  activiteit  voor  elk  onderdeel  van  de  Nederlandse 
Krijgsmacht.  Er  wordt  dan  ook  een  veelvoud  van  berichten  uitgewisseld  met  de  andere 
onderdelen  van  de  Nederlandse  strijdkrachten  en  met  de  diverse  NATO  partners.  De  overdracht 
van  deze  berichten  dient  snel  en  efficient  te  geschieden  en  de  informatie  die  in  deze  berichten  ligt 
opgeslagen  dient  kort  en  bondig,  nauwkeurig,  aktueel  en  begrijpbaar  te  zijn. 

Het  C^-systeemconcept  van  de  KL  dat  is  ontwikkeld  voor  systemen  van  ILK  geeft  aan  dat  de 
gegcvensoverdracht  tussen  de  verschillende  C^-systemen  in  principe  zal  geschieden  op  basis  van 
tekstgeorienteerde  ADatP-3  geformatteerde  berichten.  Binnen  het  ILK  zal  dit  streven  tot  op 
brigade  niveau  worden  doorgevoerd.  M.b.t.  de  andere  NATO  partners  zal  de  communicatie  op 
basis  van  geformatteerde  berichten  vooralsnog  beperkt  blijven  tot  het  LK  niveau. 

Bij  het  opstellen,  verzenden,  ontvangen  en  verwerken  van  (NATO)  militaire  geformatteerde 
berichten  blijkt  geautomatiseerde  ondersteuning  noodzakelijk.  Niet  alleen  is  een  handmatige 
aanpak  tijdrovend,  ook  is  de  kans  op  het  produceren  van  fouten  in  dat  geval  onacceptabel  grooL 

Voor  de  automatische  verwerking  van  berichten  dienen  er  standaarden  te  zijn. 

FORMETS,  zoals  beschreven  in  ADatP-3,  is  momenteel  het  enige  geaccepteerde  systeem  voor  de 
prouukiic  van  geformatteerde  berichten  binnen  de  NATO  en  wordt  toegepast  binnen  de 
commandovoeringssystemen  van  de  strijdkrachten  van  de  NATO.  Naarmate  de 
commandovoering  meer  en  meer  wordt  geautomatiseerd  neemt  het  belang  van  interoperabiliteit 
tussen  de  commandovoeringssystemen  steeds  verder  toe. 
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Het  werken  met  ADatP-3  heeft  voor-  en  nadelen. 

Voordelen  van  ADatP-3  zijn: 

•  Standaardisatie  op  een  eenduidig  berichtformaat  binnen  de  NATO. 

•  De  berichtformaten  zijn  automatisch  verwerkbaar. 

Automadsche  verwerking  van  een  artifici<?ie  taal  is  efficifinter  dan  van  een  natuurlijke 
taal. 

•  De  berichtformaten  zijn  ook  bruikbaar  zonder  ADP  support. 

Nadelen  van  ADatP-3  zijn: 

•  Het  ontbreekl  ADatP-3  op  dit  moment  aan  voldoende  middelen  om  de  semantiek  van  de 
berichten  op  een  eenduidige  manier  te  kunnen  beschrijven. 

•  Er  is  een  zekere  inconsistentie  tussen  een  aantal  berichtformaten  wegens  het  ontbreken 
van  een  gemeenschappelijk  conceptueel  model. 

•  De  betekenis  van  elementaire  gegevens  is  niet  op  een  consistente  manier  gedefinieerd.  Dit 
is  ook  vanwege  het  ontbreken  van  een  gemeenschappelijk  conceptueel  model. 

•  ADatP-3  is  omvangrijk. 

•  De  berichtformaten  zijn  moeilijk  te  doorgronden  zonder  ADP  support.  Het  aantal  bericht¬ 
formaten  is  omvangrijk  en  de  structuur  van  de  berichtformaten  is  vaak  complex. 

•  ADatP-3  is  geschikt  gemaakt  voor  geautomatiseerde  verwerking,  echter  niet 
geoptimaliseerd: 

Automatisch  verwerken  (doorgronden)  van  grote  stukken  ongestructureerde  tekst 
is  niet  of  met  veel  moeite  mogelijk. 

Conditionele  verwerking  is  nog  niet  geformaliseerd. 

De  structuur  van  berichten  (onderdelen)  sluit  niet  altijd  goed  aan  bij  de  structuur 
van  een  (relationele)  database. 

Veldconversies  zijn  niet  alUjd  triviaal. 

Peperkihgen  vanuit  communicatie  medium,  zoals  niaximale  regellengie  van  69 
karakters  (telex). 

•  Acceptatie  door  de  ofwradoncle  gebruiker  is  niet  altijd  even  goed. 


TNO-rapport 


Pagina 

6 


De  indnik  bestaat  dat  niet  iedereen  doordrongen  is  van  het  nut  van  een 
stanaaardisatie  van  de  berichtgeving. 

Vanuit  de  opek’ationele  gemeenschap  bestaat  de  indmk  dat  zij  nauwelijks  invloed 
heeft  op  de  ontwikkeling  van  deze  standaards. 

De  standaards  worden  lang  niet  altijd  als  gebruikersvriendelijk  ervaren. 

Ce  problemen  van  ADatP-3  zijn  niet  onoveikomelijk.  In  het  kader  van  het  "ADSIA/NUNN 
initiatief '  zijn  met  betrekking  tot  "NATO  Procedural  Interoperability  Standards"  (NPIS)  projecten 
opgestart,  die  de  problemen  m.b.t.  de  definitie  en  het  beheer  van  (elementen  van)  berichtfonnaten 
moeten  verminderen.  Systemen  met  geautomatiseerde  ondersteuning  kunnen  ook  goede 
mogelijkheden  bieden  voor  berichtenverwerking,  maar  deze  systemen  worden  dan  echter  wel 
complexer.  Het  belangrijkste  is  dat  er  een  standaard  is  voor  geautomatiseerde  verwerking  van 
berichten. 

Evenals  in  de  militaire  wereld  wordt  in  de  civiele  wereld  informatie  tussen  (intemationale) 
organisaties  (partners)  uitgewisseld  en  hiertoe  is,  om  wildgroei  te  voorkomen,  de  EDEFACT 
standaard  gedefinieerd,  die  te  vergelijken  is  met  ADatP-3. 

Er  kan  niet  gezegd  worden  dat  EDIFACT  te  veikiezen  is  boven  ADatP-3,  omdat  EDIFACT 
behalve  een  aantal  voordelen  ook  nadeien  kent  in  vergelijking  met  ADatP-3. 

De  verwerking  van  (geformatteerde  ADatP-3)  berichten  kan  geschieden  door  een  zogenaamd 
berichtenverweikingssysteem  (Engels:  Message  Handling  System,  afgekort  met  MHS). 

Binnen  een  MHS  zijn  vier  hoofdfuncties  te  onderscheiden:  de  berichten  I/O,  de  operator  interface, 
de  database  verwerking  en  het  beheer  van  de  lokale  berichtformaten.  VoUedig  automatische 
verwerking  met  een  interface  naar  de  operationele  database  is  een  relatief  nieuwe  ontwikkeling  en 
zal  zich  in  een  nieuwe  generatie  van  C^-systemen  gaan  manifesteren. 
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Figuur  0.1:  Top  level  dataflow  diagram  van  een  MHS. 

Bij  automatischc  vcrwerking  en  preparatie  van  (ADalP-3)  berichten  met  gegevens  voor  en  in  een 
opcrationele  database  kunnen  een  aantal  problemen  optreden: 

1)  Niet  triviale  veldconversies. 

2)  Hct  nict  in  het  bericht  en/of  database  voorkomen  van  noodzakelijke  waarden. 

3)  Hct  nict  goed  aansluitcn  van  bericht-  en  databasestructuren. 

4)  Conflictcn  bij  tegenstrijdige  en  gedateerde  berichtgeving. 
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Er  zijn  een  aantal  systemen  ontwikkeld  die  ondersteuning  bieden  bij  de  (automatische) 
verwerking  van  berichten.  Een  tweetal  systemen,  JAMPS  en  IRIS,  is  in  het  kader  van  bet  project 
onderzocht.  Beide  produkten  zijn  beschikbaar  op  een  PC  en  omvatten  momenteel  alleen  de 
functionaliteit  m.b.t.  de  preparatie  van  berichten  en  hebben  geen  interface  met  een  operationele 
database.  IRIS  is  hierbij  gebaseerd  op  ADatP-3  en  JAMPS  op  een  vergelijkbare  Amerikaanse 
standaard. 

In  het  kader  van  het  ADSIA/NUNN  project  6  wordt  er  gewerict  aan  een  AMH,  dat  gebaseerd  is  op 
IRIS.  De  specificatie  van  deze  AMH  gaat  uit  van  zowel  de  preparatie  van  geformatteerde 
berichten  als  de  geautomatiseerde  verweildng  van  inkomende  berichten  in  een  operationele 
database.  Tevens  bevat  het  systeem  een  interface  naar  communicatiemedia. 

De  AMH,  waarvan  de  werking  tijdens  een  demonstratie  is  aangetoond,  kan  bruikbaar  zijn  voor  de 
KL  bij  het  realiseren  van  bun  CPCN.  Is  het  niet  het  complete  kant  en  klare  systeem,  dan  wel  de 
applicatic  bibliotheken,  die  de  bouwstenen  voor  de  AMH  of  een  eigen  te  ontwikkelen  berichten- 
verwerkingssysteem  bevatten. 

Een  uitgebrcide  evaluatie  van  de  AMH  zal  moeten  volgen  om  de  exacte  bruikbaarheid  aantonen. 

Standaardisatie  m.b.t.  ADatP-3,  OSI,  POSIX,  SQL  en  X-Windows  biedt  een  goede  basis  voor  de 
ontwikkcling  van  een  dergelijk  CPCN.  Duidelijk  is  dat  de  vier  hoofdfuncties  van  een  MHS  op 
vcrschillendc  workstations  kunnen  en  zullen  worden  geimplementeerd. 

AdatP-3  en  bcrichtenverwerkingssystemen,  zoals  de  AMH,  zullen  ook  in  de  periode  na  1995  nog 
een  bclangrijk  element  zijn  binnen  een  tactisch  netwerk  voor  de  landstrijdkrachten. 

Informatie  overdracht  op  het  niveau  van  geformatteerde  berichten  zou  in  de  komende  jaren  echter 
plaats  kunnen  gaan  maken  voor  informatie  overdracht  tussen  de  operationele  databases  van 
diverse  C^-systemen.  Dit  is  dan  te  danken  aan  het  ATCCIS  programma.  Indien  het  ATCCIS 
programma  slaagt,  dan  zal  de  interoperabiliteit  sterk  verbeteren.  Voor  interoperabiliteit  is 
namelijk  niet  alleen  een  gcmcenschappclijke  communicatie  van  belang  maar  ook  een 
gemeenschappclijk  bcgrip  van  de  informatie  die  wordt  overgedragen.  ATCCIS  beoogt  juist  dat  te 
bcreikcn  door  te  wcrken  aan  een  informatie  model  en  een  data  element  dictionary. 
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Binnen  het  C^-filosofie  van  de  KL  zou  men,  in  navolging  van  het  Tri-MNC  CIS  concept,  een 
tweedeling  tussen  een  gebruikersdomein  en  een  iranspondomein  kunnen  aanbrengen.  Binnen  het 
gebruikersdomein  zijn  een  viertal  soorten  functies  gedefinieerd,  en  wel  informatieverwericende 
systemen,  teleservice  functies,  gateway  en  distributie  functies  en  controle  en  management 
functies. 

Binnen  het  transportdomein  zijn  alle  functies  gedefinieerd  die  nodig  zijn  om  verschillende 
gebruikersdomeinen  met  elkaar  te  verbinden.  In  deze  opzet  behoort  het  gehele  CPCN  concept  van 
de  KL  tot  het  gebruikersdomein  en  het  ZODIAC  netwerk  tot  het  transportdomein. 

Alle  gebruikers  zouden  toegang  moeten  krijgen  tot  een  telefoon  service  en  een  MHS.  Specifieke 
gebruikers  die  gebruik  maken  van  een  multifunctioneel  werkstation  krijgen  toegang  tot  databases, 
beschikken  over  een  MHS  op  basis  van  geformatteerde  berichten  (ADatP-3)  en  maken  gebruik 
van  alle  teleservices.  Naast  datacommunicatie  faciliteiten  krijgen  sommige  gebruikers  ook  de 
mogelijkheid  om  grafische  informatie  uit  te  wisselen. 
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1 .  Inleiding 

In  juni  1991  heefi  de  Koni.iklijke  Landmacht  (KL)  bij  het  FEL-TNO  een  opdracht  geplaatst  om 
onderzoek  te  doen  naar  de  geautomatiseerdc  verweiidng  van  (NATO)  militaire  berichten.  Dit  om 
interoperabiliteit  binnen  de  krijgsmacht  en  tussen  NATO  krijgsmachien/partners  te  verbeteren. 

Dit  document  bevat  de  resultaten  van  het  onderzoek  (opdracht  A91KL645)  naar  verbetering  en 
automatisering  van  het  lekstgeoi  ienteerde  berichtenverkeer  binner.  de  krijgsmacht  en  tussen 
NATO  krijgsmachten. 

Ii.  hoofdsluk  2  wordl  de  probleemstelling  nader  uitgewerkt,  waama  in  de  hoofdstukken  3  en4 
ingegaan  wordt  op  de  structuur  van  de  berichten  en  de  functionaliteit  van  het  verwerken  van 
berichten.  In  hoofdstuk  5  worden  reeds  bestaande  systemen  besproken  en  in  de  hoofdstukken  6 
en  7  een  systcem  in  ontwikkeling  en  het  belang  van  diverse  ontwikkelingen  op  dit  gebied  voor  de 
KL.  Tenslotte  worden  in  ’■loofdstuk  8  conclusies  en  aanbevelingen  gepresenteerd. 
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2.  Probleemsteliing 

E>e  uitwisseling  van  informatie  is  een  essentiSle  activiteit  voor  elk  onderdeel  van  de  Nederiandse 
Krijgsmacht.  Er  wordt  dan  ook  een  veelvoud  van  berichten  uitgewisseld  met  de  andere 
onderdelen  van  de  Nederiandse  strijdkrachten  en  met  de  diverse  NATO  partners.  De  overdracht 
van  deze  berichten  dient  snel  en  efficient  te  geschieden  en  de  informatie  die  in  deze  berichten  ligt 
opgeslagen  dient  kort  en  bondig,  nauwkeurig,  aktueel  en  begrijpbaar  te  zijn. 

Standaardisatie  van  de  berichtenstroom  verbetert  de  interoperabiliteit  (gegevensuitwisseling, 
samenwerking)  tussen  de  verschillende  nationale  en  intemationale  autoriteiten  en  systemen 
aanzienlijk.  Het  streven  naar  interoperabiliteit  wordt  verder  versterkt  door  de  politieke 
ontwikkelingen  die  de  afgelopen  tijd  plaatsvinden  binnen  Europa.  Defensiebudgetten  zullen  de 
komende  jaren  krimpen,  waardoor  de  operationele  staven  en  de  technische  middelen  worden 
gereduceerd.  Om  dit  enigszins  te  compenseren  is  het  noodzakelijk  om  alle  beschikbare  middelen 
beier  te  cobrdineren,  bijvoorbeeld  door  de  formatie  van  multi-nationale  sterk  gespecialiseerde 
inten/entiemachten  [SHAPE91.  NACISC:91b]. 


NAVO 

p«rtner 


♦ 


V 


ADatP'3 

— > 

anders 

— 

organ  ttatoriacha 

Ink 

Figuur  2. 1 :  Beoogd  en  ingeschat  loepassingsgebied  van  ADatP-3 


Het  C^-systccmconccpt  van  dc  KL  dal  is  ontwikkcld  voor  systemen  van  ILk  gceft  aan  dat  de 
gegcvensovcrdracht  tussen  dc  verschillende  C^-sysiemen  in  principc  zal  geschieden  op  basis  van 
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tekstgeoriemeerde  geformatteerde  berichten.  Deze  keuze  (ook  conform  het  Tri-MNC  CIS  concept 
[SHAPE91,  NACISC91b])  is  ingegeven  door  de  beperkte  beschikbare  transmissiecapaciteit 
(zowel  in  kwalitatieve  als  in  kwantitatieve  zin)  en  interoperabiliteitseisen. 

Voorbeelden  van  in  ontwikkeling  zijnde  en  geplande  C^-sysiemen  welke  van  dit  concept  uitgaan 
zijn; 

•  Gevechtsinformatiesysteem  t.b.v.  het  AD  Source  Information  Centre  van  de  sectie  G2. 

•  System  control  en  management  systeem  t.b.v.  de  bedrijfsvoering  van  ZODIAC. 

•  Commandopost  inform  atiesysteem  t.b.v.  de  ondersteuning  van  het  BVT  (beoordeling  van 
de  toestand)  proces  binnen  de  grote  staven. 

•  Speciale  systemen  voor  de  Genie,  Artillerie,  Verkeer  en  vervoer,  etc. 

•  Bedrijfsvoeringssystemen  zoals  personeelsaanvuUing  en  logistieke  systemen. 

De  toepassing  van  de  ADatP-3  regelgeving  heeft  voor  het  hiervoor  geschetste  concept  goede 
mogelijkheden,  niet  alleen  voor  communicatie  extern  maar  ook  voor  communicatie  intern  tussen 
deelsystemen. 

Het  opstellen,  verzenden,  ontvangen  en  verwerken  van  (NATO)  militaire  geformatteerde 
berichten  is  echter  tijdrovend.  Procedures,  zoals  vastgelegd  in  Allied  Data  Publications 
(bv.  ADatP-3),  Allied  Communications  Publications  (bv.  ACP127)  en  andere  NATO  standaarden, 
leiden  aan  de  ontvangstzijde  tot  een  beter  begrip  m.b.t.  de  inhoud  van  een  bericht,  maar  zijn 
tegelijkertijd  verantwoordelijk  voor  een  tijdrovende  opstel-  en  interpretatiefase.  Bovendien 
worden  onvermijdelijk  (interpretatie)  fouten  gemaakt  die  kunnen  leiden  tot  het  nemen  van 
verkeerde  beslissingen  op  de  betrokken  commandoniveaus.  Deze  fouten  worden  veelal 
veroorzaakt  door  het  (bij  de  gebruikers)  ontbreken  van  begrip  en  kermis  van  de  structuur  van  elk 
type  bericht. 

De  oplossing  kan  worden  gezocht  in  automatisering  van  de  berichtgeving. 

Maar  ook  indien  het  begrip  en  de  kermis  van  de  structuur  van  berichten  aanwezig  is  in  een 
computersysteem,  dan  kunnen  er  problemen  optreden  bij  het  (automatisch)  verwerken  (opsteUen, 
interpreteren)  van  een  geformatteerd  (b.v.  ADatP-3)  bericht.  De  structuur  van  een  bericht  kan 
afwijken  van  de  structuur  van  de  opcrationele  database  waardoor  het  leggen  van  een  nelatie  tussen 
bcrichi(formaat)  en  een  database  niet  mogelijk  of  bijzonder  complex  is. 

De  structuur  van  de  berichten  is  centraal  vastgelegd  (bij  ADSIA),  maar  de  structuur  van  een 
opcrationele  database  niet. 
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Naar  aanleiding  van  de  behoefte  van  verschillende  organisaties  om  gegevens  over  een  bepaald 
gemeenschappelijk  domein  uit  te  wisselen  word!  een  berichtformaat  afgesproken  waarin  alle  (de 
meeste)  uit  te  wisselen  informatie  opgenomen  kan  worden.  Het  is  echter  moeilijk  om  een 
consistent  berichtformaat  te  ontwerpen,  omdat  er  geen  gemeenschappelijk  conccptueel  model 
aanwezig  is.  Dit  laatste  kan  ook  problemen  geven  voor  applicaties  die  gebruik  maken  van 
gegevens  in  een  bericht  of  gegevens  moeten  leveren  voor  het  aanmaken  van  een  bericht,  omdat  de 
afbeelding  van  het  conceptuele  model  waarop  de  applicatie  is  gebaseerd  niet  geheel  overeenstemt 
met  de  stnictuur  en/of  formaat  van  gegevens  in  een  bericht. 

Tenslotte  dient  te  worden  vermeld  dat  berichtformaten  al  geruime  tijd  beschikbaar  zijn  en 
duidelijk  hebben  aangetoond  dat  het  in  de  praktijk  brengen  van  dergelijke  standaards  een  aantal 
problemen  met  zich  meebrengt: 

•  De  indruk  bestaat  dat  niet  iedereen  doordrongen  is  van  het  nut  van  een  standaardisatie  van 
de  berichtgeving.  Met  name  op  het  niveau  van  de  manschappen  in  het  veld  wordt  een 
nieuwe  stringente  regelgeving  op  dit  gebied  gezien  als  een  nodeloze  complicatie.  ZiJ  zijn 
tevreden  met  de  bestaande  procedures. 

•  Vanuit  de  operationele  gemeenschap  bestaat  tevens  de  algemene  indruk  dat  zij  nauwelijks 
invloed  heeft  op  de  ontwikkeling  van  deze  standaards. 

•  De  standaards  worden  lang  niet  altijd  als  gebruikersvriendelijk  ervaren,  zij  worden  ook 
wel  gezien  als  zijnde  toegesneden  op  machines  en  daardoor  minder  geschikt  voor  de 
operationele  gebruiker. 

•  Sommige  gebruikers  geloven  dat  zij  experts  moeten  zijn  met  betrekking  tot  het  lezen  en 
opstellen  van  alle  berichten. 

Dit  onderzoeksproject  richt  zich  op  de  eerste  plaats  op  het  vinden  van  een  goede  oplossing  voor 
de  genoemde  technische  problemen. 
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3.  Berichtstructuur 

3.1  Inleiding 

Voor  het  berichtenverkeer  tussen  en  binnen  organisaties  kan  een  natuurlijke  taal 
(ongestructureerde  tekst)  worden  gebruikt.  Deze  manier  van  weilcen  is  flexibel,  maar  heeft  een 
aantal  belangrijke  nadelen.  Ongestructureerde  teksten  geschreven  in  natuurlijke  taal  kunnen  over 
het  algemeen  niet  snel  worden  verwerkt,  omdat  de  zinnen  veel  overtollige  woorden  bevatten  en  de 
woorden  vaak  meer  dan  66n  betekenis  hebben.  Voor  de  geautomatiseeide  verwerking  m.b.v. 
computers  is  deze  manier  van  weiken  verre  van  optimaal. 

Een  manier  om  het  berichtenverkeer  beter  te  stroomlijnen  is  het  defmigren  van  een  standaard  door 
middel  van  een  artificiSle  taal.  Het  vocabulair  van  deze  artificieie  taal  kan  zodanig  worden 
begrensd  zodat  alle  woorden  (begrippen)  een  eenduidige  betekenis  hebben.  Dit  is  een  belangrijk 
voordeel  binnen  intemationale  organisaties  waar  meerdere  natuurlijke  talen  naast  elkaar  bestaan. 
Met  een  vaste  structuur  (syntax)  kan  worden  bereikt  dat  er  veel  informatie  wordt  doorgegeven 
door  de  positionering  van  de  woorden,  waardoor  een  bericht  compact  blijft.  Een  voorbeeld 
hiervan  is  weergegeven  m.b.v.  de  figuten  3.1  en  3.2. 


EXERCISE:  TEST  MESSAGE 
SUBJECT;  SEVERE  WEATHER  WARNING 

HQ  41 H  ARMDIV  ISSUES  THE  FOLLOWING  SEVERE  WEATHER  WARNING  (002JUL90): 

HEAVY  THUNDERSTORMS  ARE  EXPECTED  DURING  THE  PERIOD  171200Z  TO  171500Z  JUL90. 
PRESENT  LOCATION  OF  STORM  CENTER  IS;  4523.1N12246.2W. 

MINIMUM  FORECAST  CEIUNG  DURING  THIS  PERIOD  IS  100  FT  AGL.  MAXIMUM  FORECAST 
WINDSPEED  IS  20  KTS  WITH  PEAK  GUSTS  TO  50  KTS.  FROM  340  DEGREES  TRUE.  MINIMUM 
EXPECTED  VISIBILITY  IS  500  METERS. 

THUNDERSTORM  MOVEMENT  IS  FROM  NORTHWEST  TO  SOUTHEAST. 


Fig.  3.1:  Voorbeeld  bericht  in  natuurlijke  taal 

De  tekst  in  Tiguur  3.1  bevat  bijna  500  karakters.  Dezelfde  infoimatie  uit  deze  figuur  kan  ook 
kortcr  weergegeven  worden  zoals  getoond  in  figuur  3.2,  waar  de  tekst  uit  ongeveer  200  karakters 
bestaat. 
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EXER/TEST  MESSAGB/ 

MSGID/SVRWXWARN/4ARMDIV/002/JUU/ 

SEVERWX/HVYTSTM// 

WEATHLOC/4523. 1 N 1 2246.2W// 

PERID/1 71 2002/T0:1 71500Z// 

WEATH/HVYTST/VIS:500M/MINCEL:  1 00/WNDSPD:20/G:5(VWINDI  R:340// 
CLOSTEXT/TSTM  MOVEMENT  IS  FROM  NORTHWEST  TO  SOUTHEAST// 


Fig.  3.2:  Voorbeeld  bericht  in  artificiSle  taal 


Een  belangrijk  voordeel  is  dat  automatische  verwerking  van  een  artificigle  taal  veel  efficienter  is 
dan  de  automatische  verwerking  van  een  natuurlijke  taal. 

De  algemene  structuur  van  een  bericht  dat  op  elektronische  wijze  verstuurd  wordt,  bestaat  in 
vergelijking  met  de  'papieren  post’  ook  uit  een  berichttekst,  die  alle  informatie  bevat  met 
betrekking  tot  het  onderwerp  waar  het  werkelijk  om  gaat,  en  een  ’envelop’  die  de  berichttekst 
omsluit  en  die  specifieke  (voor  het  communicatie  medium  benodigde)  informatie  (o.a.  adressen 
van  afzender  en  bestemming)  bevat  voor  de  communicatie.  Deze  structuur  is  weergegeven  in 
figuur  3.3. 


Envelop: 

•  AdrM  wmndtr 

•  AdrM  ontvanger 


Figuur  3.3: 


Algemene  structuur  bericht 
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Voor  de  automatische  verwerking  van  een  bericht  dienen  er  noimen  (standaaiden)  te  zijn  voor  de 
berichttekst  en  de  'envelop'.  Een  standaard  van  een  'taal'  voor  definitie  van  een  envelop  is 
gespecificeerd  in  Allied  Communication  Publication  127  (ACP  127).  Op  de  standaards  voor 
enveloppen  wordt  in  dit  rapport  niet  verder  ingegaan.  In  bet  vervolg  van  dit  boofdstuk  wordt 
nader  ingegaan  op  ADatP-3  en  EDIFACT,  respectievelijk  de  militaire  en  civiele  standaaiden  vjor 
de  formattering  van  een  bericbttekst. 
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3.2 

ADatP-3 

3.2.1 

Achtergrond 

Het  NATO  Message  Text  Formatting  System  (FORMETS)  voorziet  in  de  standaardisatie  van 
karaktergeorignteerde  berichten.  FORMETS  is  een  verzameling  van  standaarden  die  samen  een 
artificiele  taal  vcrmen  die  bruikbaar  is  voor  het  uitwisselen  van  militaire  berichten.  Deze 
standaaiden  definieren  samen  de  regels  die  gelden  voor  de  representatie  van  berichtonderdelen  en 
de  methoden  volgens  welke  regels  toegepast  dienen  te  worden.  Het  resultaat  is  een  onbegrensde 
opsomming  van  algemeen  goedgekeurde  representaties,  zinstructuren  en  berichtstructuren. 
FORMETS  maakt  hierbij,  zoals  aangegeven  door  het  NATO  Interoperability  Management  Plan 
(NIMP),  zoveel  mogelijk  gebruik  van  andere  NATO  standaarden,  zoals  de  vastgestelde  NATO 
terminologie. 

FORMETS  biedt  de  regels,  constructies  en  vocabulair  voor  een  karaktergeorignteerde  standaard 
voor  berichtformaten  die  worden  gebruikt  binnen  de  commandovoeringssystemen  van  de  NATO. 
Deze  definities  kunnen  zowel  voor  manuele  operatic  alsmede  voor  de  geautomatiseerde  operatic 
worden  benut.  De  berichten  die  worden  gemaakt  met  behulp  van  FORMETS  worden 
geformatteerde  berichten  genoemd. 

FORMETS  is  momenteel  het  enige  geaccepteerde  systeem  voor  de  produktie  van  geformatteerde 
berichten  binnen  de  NATO  en  wordt  toegepast  binnen  de  commandovoeringssystemen  van  de 
strijdkrachten  van  de  NATO.  Naarmate  de  commandovoering  meer  en  meer  wordt 
geautomatiseerd  neemt  het  belang  van  interoperabiliteit  tussen  de  commandovoeringssystemen 
steeds  verder  toe. 

FORMETS  is  vastgelegd  binnen  de  Allied  Data  Publications  [ADatP-3(l-5)],  de  zogeheten 
ADatP-3  standaard. 

De  ADatP-3  publicatie  is  voomamelijk  bedoeld  voor  diegenen  die  bezig  zijn  met  het  ontwikkelen 
en  implementeren  van  berichtformaten.  Deel  I  van  de  publicatie  bevat  de  beschrijving  van 
FORMETS,  delen  II,  III  en  IV  voorziet  in  een  catalogus  van  alle  opgenomen  bericht-,  set-  en 
vcld-formaten  en  deel  V  voorziet  in  een  index.  De  binnen  NATO  vastgestelde  berichtformaten 
zijn  opgenomen  in  FORMETS.  Bij  ADSIA  is  een  Master  Development  DataBase  (MDDB) 
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aanwezig  waarin  informatie  over  alle  nog  in  ontwikkeling  zijnde  (NATO)  berichtformaten  is 
opgenomen. 

De  ADatP-3  standaard  wordt  ondeihouden  door  zogeheten  Functional  Segment  Development 
Working  Groups  (FSDWGs).  Dit  zijn  multinationale  werkgroepen  die  verantwoording  afleggen 
aan  de  Allied  Data  Systems  Interoperability  Agency  (ADSIA),  voor  wat  betreft  de  ontwikkeling 
van  karaktergeorienteerde  procedurele  interoperabiliteit  standaarden  (NPIS)  op  de  functioneel 
gescheiden  deelgebieden  die  hun  zijn  toebedeeld.  Er  zijn  5  werkgroepen,  ieder  met  him  eigen 
deelgebied; 

WG2  -  MTF  Air  Operations 

WG3  -  MTF  Land  and  Combined  Actions 

WG5  -  MTF  Language  Development  and  Configuration  Management 
(onderhoud  van  ADatP-3  standaard  in  technische  zin) 

WG6  -  MTF  Maritime  Operations 
WG7  -  MTF  Intelligence  Operations 

Daamaast  zijn  er  een  tweetal  zogeheten  Data  Link  Develoment  Working  Groups  (DLDWGs)  die 
zich  bezig  houden  met  bitgeorignteerde  procedurele  interoperabiliteit  standaarden  (vastgelegd  in 
STANAG  serie  55xx).  Deze  twee  werkgroepen  zijn; 

WGl  -  Maritime  Data  Links 
WG4  -  Joint  Data  Links 

3.2.2  Berichtstructuur 

De  algemene  stnictuur  (syntax)  van  een  ADatP-3  bericht(formaat)  staat  beschreven  in 
[ADatP-3(l)].  Met  behulp  van  de  NIAM-methode  is  getracht  deze  stnictuur  te  modelleren.  In 
bijlage  A  zijn  NIAM-diagrammen  opgenomen  die  de  structuur  (componenten)  van  een  bericht- 
formaat  en  een  geformatteerd  bericht  beschrijven.  Deze  structuur  is  toegespitst  op  ADatP-3. 

Een  berichtformaat  is  samengesteld  uit  set-  en  veld-formaten  en  verschaft  informatie  over  een 
bepaald  onderwerp.  In  een  ADatP-3  berichttekst  zijn  velden  en  sets  qua  structuur  equivalent  met 
zirmen  en  woorden  in  de  natuuilijke  taal.  Het  formaat  (type)  van  een  bericht  wordt  in  het  bericht 
zelf  vermeld  en  wel  in  een  berichtonderdeel  dat  in  elk  bericht  aanwezig  moet  zijn. 
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3.2.2. 1  Berichtformaten 

Een  berichtformaat  bestaat  (op  het  hoogste  niveau)  uit  een  aantal  onderdelen  (sets,  zinnen;  zie 
figuur  3.4  en  het  NIAM-diagram  'berichtformaat'  in  bijlage  A),  die  informatie  verschaffen  over 
entiteiten  m.b.t.  het  onderwerp.  Deze  berichtonderdelen  kennen  een  ordening  en  groepering.  Het 
doel  van  een  berichtformaat  bepaalt  de  context  waarin  de  onderdelen  gebruikt  worden.  Een 
onderdeel  kan  in  een  aantal  berichtformaten  gebruikt  worden,  maar  met  een  verschillende 
betekenis. 

Afhankelijk  van  de  definitie  van  een  berichtformaat  kunnen  berichtonderdelen  (onbeperict) 
herhaald  worden  (RPT  =  *)  en  is  het  gebruik  ervan  veiplicht,  optioneel  of  conditioneel  (OCC  = 
M(andatory),  O(ptional)  or  C(onditional)).  In  het  laatste  geval  is  een  conditie  gespecificeerd 
waaronder  het  berichtonderdeel  gebruikt  dient  te  worden. 


MESSAGE  TEXT  FORMAT  NAME:  MCM  SITREP  ONE 


SEG  RPT 

OCC 

SETID 

SET  FORMAT  NAME 

(C) 

EXER 

EXERCISE  IDENTIFICATION 

(C) 

OPER 

OPERATION  CODEWORD 

(M) 

MSGID 

MESSAGE  IDENTIFIER 

(M) 

MTASK 

MCM  TASK 

(M) 

MSUM 

SUMMARY  OF  MINEFINDS 

( 

(C) 

MINE 

MINE  INFORMATION 

( 

(C) 

AMPN 

AMPLIFICATION 

END  OF  SEGMENT 

(O) 

PGRSS 

PROGRESS  OF  MCM  TASK 

• 

(O) 

UWCOND 

UNDERWATER  CONDITIONS 

• 

(0) 

CONMARK 

CONTACT  MARKER 

Figuur  3.4:  Voorbeeld  berichtformaat 


Een  berichtonderdeel  kan  tesamen  met  een  aantal  volgende  onderdelen  een  groep  (segment) 
vormcn  (SEG  =  '(').  De  onderdelen  van  een  segment  zijn  aan  elkaar  gerelateerd  vanwege  de 
relaties  tussen  de  entiteiten  waarovcr  ze  informatie  verschaffen.  Een  segment  kan  ook  weer  een 
ander  (genest)  segment  bevatten  en  segmenten  kunnen  zich  herhalen. 

3. 2. 2.2  Setformaten 

Een  sctformaat  (zin)  bestaat  ook  uit  een  aantal  onderdelen  (zie  figuur  3.5  en  het  NIAM-diagram 
'setformaat'  in  bijlage  A).  Deze  zinonderdelen  verschaffen  informatie  over  de  attributen  van  een 
entiteit  en  kennen  evenals  de  berichtonderdelen  een  ordening  en  een  verplicht,  optioneel  of 
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conditioneel  gebniik  (FF-SEQ  =  *,  voignummer,  M/O/C).  De  positie  in  de  set  bepaald  de 
betekenis  van  het  onderdeel.  Er  is  echter  ook  een  groepering  mogelijk,  die  afwijkt  van  die  voor  de 
berichtonderdelen.  Om  herhalende  typen  infonnatie  weer  te  geven  kunnen  de  laatste  onderdelen 
(velden)  in  een  set  een  groep  vormen  en  als  zodanig  (onbeperkt)  herhaald  worden. 

De  verschillen  sets  in  een  bericht  worden  van  elkaar  onderscheiden  d.m.v.  een  aanduiding  aan  het 
begin  van  elke  set. 


SET  FORMAT  NAME;  MCM  TASK 


FF-SEQ 

FIELD  USE  DESIGNATOR  FLD  DESC 

ALT 

FFIRN/FUDN 

1  M 

MCM  TASK  ORDER  NUMBER 

1012A)38 

2M 

SHIP  NAME 

A 

1022AM9 

TASKED  UNIT 

B 

1028A>10 

30 

O-ROUTE 

A 

2006/001 

MCM  AREA  NAME 

B 

1022A)27 

AREA  OF  OPERATIONS  REFERENCE 

C 

1094AX)1 

MO 

TIME  MODIFIER 

1143AX)1 

*50 

VERIFIED  DAY-TIME  OF  MCM  TASK 

MESSAGE 

2013/016 

EXAMPLES: 

MTASK/1 OOOG1  /ALKMAAR/AREA1 2/ON/I  71 200Z  1/OFF/I  81 200Z2// 
MTASK/1050N2/123.4.5/100A-D/ON/230730Z5// 


Figuur  3.5:  Voorbeeld  setformaat 


Voor  een  zinondcrdeel  kunnen  aan  aantal  altematieve  veldformaten  gespecificeerd  zijn  (ALT, 
FFIRN/FUDN  (field  format  index  reference  number,  field  use  designator  number)).  In  figuur  3.5 
zijn  voor  de  velden  2  en  3  altematieve  formaten  vermeld.  Voor  een  altematief  kan  eventueel  een 
descriptor  (FLD  DESC)  gespecificeerd  zijn  die  dan  in  een  bericht  (ter  verduidelijking) 
opgenomen  moet  worden  ter  verduidelijking  van  de  exacte  betekenis  van  het  gebruikte  veld- 
formaat,  indien  die  niet  afleidbaar  is  uit  het  formaat  (de  karakters)  van  het  veld.  Voor  het  gebruik 
van  een  altematief  kan  een  conditie  gespecificeerd  zijn. 

Het  hiervoor  beschreven  setformaat  is  een  lineair  setformaat  met  allc  informatie  achter  elkaar. 

Om  nu  de  leesbaarheid  (voor  een  gebruiker)  te  vergroten  zijn  er  een  aantal  setformaten  waar  de 
informatie  in  tabelvorm  is  gestructureerd  en  zo  kan  worden  weergegeven.  Voor  de  (kolom)  zin- 
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onderdelen  wordt  een  kop  (header)  weergegeven  en  zijn  een  staitpositie  en  uitlijning 
gespecificeerd,  zodat  de  velden  op  elke  regel  precies  onder  elkaar  staan  (zie  flguur  3.6). 


5POL 

/CODE  /POL  TYPE  /CBM-OH/DOS 

/DSL456  /DIESEL  /  800/  2 

/HYDFLU  /HYDRAULICS  /  20/  2// 


Figuur  3.6:  Voorbeeld  tabelvorm  set 


3.2. 2. 3  Veldformaten 

Een  veldformaat,  de  fundamentele  bouwsteen  van  een  bericht,  kan  enkelvoudig  of  samengesteld 
(zie  flguur  3.7  resp.  3.8  en  het  NIAM-diagram  'veldformaat'  in  bijlage  A)  zijn. 

Enkelvoudige  velden  hebben  een  minimum  en  een  maximum  lengte  en  bestaan  uit  een  klasse  van 
toegestane  karakters.  Het  is  ook  mogelijk  dat  voor  een  enkelvoudig  veld  mogelijke  (discrete) 
waarden  gespecificeerd  zijn  of  een  waardenbereik  bestaande  uit  een  onder-  en  bovengrens  en  een 
datatype. 


FIELD  FORMAT  N AME :  ROUTE  POSITION  DESIGNATOR 
FFIRN:  1053 

STRUCTURE:  1-2  A 


EXAMPLES:  A,  AB,  CC 


Figuur  3.7:  Voorbeeld  enkelvoudig  veldformaat 


Samengestelde  veldformaten  bestaan  uit  (geordende)  onderdelen  die  gevormd  worden  door 
enkelvoudige  veldformaten.  Zo  kan  de  rangsehikking  van  verschillende  soorten  karakters  in  een 
veld  worden  worden  gespecificeerd.  Tevens  kunnen  door  het  gebruik  van  enkelvoudige  veld¬ 
formaten  beperkingen  op  veldonderdclcn  worden  opgelegd. 


TNO-rapport 


Pagina 

24 


FIELD  FORMAT  NAME:  Q-ROUTE 

FFIRN: 

2006 

STRUCTURE 

FFIRN/FUDN 

FIELD  USE  DESIGNATOR 

3  N 

1012/045 

Q-ROUTE  NUMBER  OF  START  POINT 

1  A 

1053/006 

START  POINT  DESIGNATOR 

1.4  NS 

1089/002 

DISTANCE  IN  NAUTICAL  MILES  FROM  START  POINT 

1  S 

1025/002 

HYPHEN 

3N 

1012/046 

Q-ROUTE  NUMBER  OF  FINISH  POINT 

1  A 

1053/007 

FINISH  POINT  DESIGNATOR 

1-4  NS 

1089/003 

DISTANCE  IN  NAUTICAL  MILES  FROM  FINISH  POINT 

EXAMPLE: 

100A0.0-100C2.5 

Figuur  3.8:  Voorbeeld  samengesteld  veldformaai 


Een  actuele  berichtteksi  (zie  figuur  3.2)  bestaat  uit  regels  die  instantiaties  zijn  van  bericht- 
onderdelen  (zie  het  NlAM-diagram  'actueel  bericht'  in  bijlage  A).  Een  regel  bestaat  uit  velden  die 
instantiaties  zijn  van  zinonderdeelaltematieven.  Een  veld  kan  uiteindelijk  bestaan  uit  instantiaties 
van  enkelvoudige  veldonderdelen. 

3.2.3  Opmerkingen 

Dc  ADatP-3  syntax  is  de  standaard  voor  eenduidige  berichtformaten  binnen  de  NATO.  Er  zijn 
echter  wel  een  aantal  kanttekcningen  te  plaatsen. 

In  de  ADatP-3  standaard  zijn  facilitciten  opgenomen  om  geformatteerde  berichten  handmatig  te 
verwerken  (i.h.b.  lezen  van  een  bericht): 

•  Bepaalde  velden  hebben  een  descriptor  die  vermeldt  wat  het  veld  inhoudt. 

•  Bepaalde  gegevens  worden  in  tabelvorm  weergegeven. 

Ondanks  dergelijke  faciliteiten  zijn  de  geformatteerde  berichten  moeilijk  te  doorgronden  zonder 
ADP  ondersteuning.  Het  aantal  berichtformaten  is  omvangrijk  en  de  structuur  van  de  bericht- 
formaien  is  vaak  complex. 
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De  structuur  (syntax;  van  ADaiP-3  kan  eenvoudiger  indien  de  berichten  met  geautomatiseerde 
ondersteuning  verwerkt  worden: 

•  Setfonnaten  in  tabelvonn  zijn  niet  nodig. 

Koppen  boven  de  kolommen  zijn  bij  ADP  niet  nodig,  evenals  bet  op  een  nieuwe  regel 
laten  beginnen  van  een  nieuwe  groep  gegevens.  Een  tabellarisch  setfoimaat  is  eigenlijk 
niets  anders  dan  een  ’nonnaal’  setformaat  met  een  (herhalende)  groep  van  velden  en  is 
alleen  maar  bedoeld  voor  presentatiedoeleinden. 

•  Een  (herhalende)  groep  van  velden  in  een  setformaat  kan  anders  geimplementeerd  worden 
door  de  betreffende  velden  in  een  apart  setformaat  te  plaalsen  en  dit  setformaat  het  'hoofd' 
setformaat  (met  sleutel inform atie)  te  laten  volgen  in  een  segment. 

Het  aanial  ADatP-3  berichtformatcr  is  omvangrijk.  Bepaalde  caicgorieen  hebben  slechts  een 
kleinc  gebruikersgroep.  Ook  is  het  zo  dat  er  overlap  bestaat  tussen  verschillende  berichtformaten, 
d.w.z.  bepaalde  structuren  van  setformaten  worden  in  een  aantal  berichtformaten  gebruikt.  Dit 
komt  omdat  men  met  de  informatie  behoefte  van  een  groot  aantal  verschillende  organisaties 
rekening  hceft  te  houden. 

Het  gebniik/vooi;  \iien  van  berichtonderdelen  (sets,  velden,  veldaltematieven)  kan  conditioneel 
zijn.  Er  is  alleen  nog  gecn  formcle  notatiewijze  voor  de  condities,  zodat  deze  niet  automatisch 
verwerkt  kunnen  worden.  Dit  problecm  is  waarschijnlijk  in  de  eersivolgende  versie  (Change  3) 
van  ADatP-3  Part  1  verholpen. 

ADatP-3  is  sterk  telexgericht  wat  blijkt  uit  de  maximale  regellengte  van  69  karakters.  Hierdoor 
kan  een  set  over  een  aantal  regels  uitgespreid  worden,  wat  weer  voor  extra  werk  zorgt  bij  de 
verwerking  ervan.  Het  telexgericht-zijn  bl.jKt  ook  uit  de  (kleine)  verzameling  van  te  gebruiken 
karakters. 

In  een  ADatP-3  bericht  kan  extra  commentaar  opgenomen  worden  in  de  vorm  van  vrije 
(ongestructureerde)  tekst.  Deze  extra  informatie,  die  soms  een  aanzienlijke  lengte  kan  hebben,  kan 
opgenomen  worden  na  berichtonderdelen  (set,  segment),  maar  ook  na  een  berichttekst. 

Het  gebruik  van  deze  mogclijkheid  duidt  crop  dat  m.b.v.  de  setformaten  in  een  bericht  niet 
voldoende  infomatic  doorgegeven  kan  worden.  Hci  automatisch  verwerken  (doorgronden)  van 
grote  stukken  ongestruct  jrcerde  tekst  is  vaak  niet  of  met  vecl  moeite  mogelijk. 
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De  betekenis  van  gegevens  is  niet  op  een  consistenie  manier  gedefinieerd.  Ook  is  het  zo  dat  het 
moe'lijk  is  om  de  data  definities  te  onderhouden.  Ter  illustratie  hiervan  wordt  hiema  een 
voorbeeld  gegeven  voor  het  verschillende  gebruik  van  het  veld  OPERATIONAL  STATUS 
(liguur  3.9). 


FUDN 

SET 

FIELD 

1 

OPERATIONAL  STATUS 

OPERATIONAL  STATUS 

2 

BASE  OPERATIONAL  STATUS 

CURRENT  BASE  OPERATIONAL  STATUS 

3 

BASE  OPERATIONAL  STATUS 

PROJECTED  BASE  OPERATIONAL  STATUS 

4 

LOSSES 

ENGAGEMENT  RESULT 

5 

CCIS  STATUS 

STATUS  OF  SYSTEM 

6 

CCIS  STATUS 

STATUS  OF  SECURITY  SYSTEM 

7 

POSITION 

READINESS  STATUS 

8 

HOSPITAL  STATUS 

BED  STATUS 

Figuur  3.9:  Gebruiksdoeleindcn  OPERATIONAL  STATUS 


Voor  elk  van  de  mogelijke  gebruiksdoeleinden  van  het  veld  zijn  mogelijke  veldwaarden  (data 
items)  gedefinieerd  (figuur  3. 10  a  en  b). 


DATA  ITEM 

FIELD  USE  DESIGNATOR  NR 

1  2  3  4  5  6  7  8 

FULLY  OPERATIONAL 

X  X 

LIMITED  OPERATIONAL 

X  X 

NON-OPERATIONAL 

X  X 

ACTIVATED 

X 

AVAILABLE 

X  X 

BLOCKED 

X 

CAPTURED 

X  X 

CLEARED 

X 

DAMAGED 

X  X 

DEACTIVATED 

X 

DENIED 

X 

DESTROYED 

X  X 

ENTERING 

X  X 

HIDING 

X 

INTERRUPTION 

X 

JAMMING 

X 

KILLED 

X  X 

LEAVING 

X  X 

MAINTAINING 

X 

MOVING 

X 

NOT  AVAILABLE 

X 

NOT  OPERATIONAL 

X  XXX 

OBSERVED 

X  X 

OCCUPATIONAL 

X 

OPERATIONAL 

X  X  X  X  X 

OUT 

X 

PARTIALLY  OPERATIONAL 

X 

Figuur  3. 10a:  Veldwaarden  OPERATIONAL  STATUS 
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DATA  ITEM 

FIELD  USE  DESIGNATOR  NR 

1  2  3  4  5  6  7  8 

REPAIRING 

X 

READY 

X  X 

SILENCE 

X  X 

TRANSFERRED 

X 

TURNED  OFF 

X  X 

WOUNDED 

X  X 

NON  OPERATIONAL  AIR  DEFENCE 

NON  OPERATIONAL  AIR  ATTACK 

NON  OPERATIONAL  AIR  STRIKE 

REDUCED  OPERATIONAL  CAPABILITY 

UNKNOWN 

(LITERAL) 

Figuur  3.10b:  Veldwaarden  OPERATIONAL  STATUS 


6ij  de  definilie  van  de  mogelijke  waarden  voor  het  veld  OPERATIONAL  STATUS  dient  een 

aantal  opmerkingen  te  worden  gemaakt: 

•  Voor  de  laatste  5  waarden  (van  NON  OPERATIONAL  AIR  DEFENCE  t/m 
UNKNOWN)  is  er  geen  FUDN  gespecificeerd. 

•  De  velden  CURRENT  BASE  OPERATIONAL  STATUS  en  PROJECTED  BASE 
OPERATIONAL  STATUS  hebben  hetzelfde  waardenbereik  (FULLY  OPERATIONAL. 
LIMITED  OPERATIONAL  en  NON-OPERATiONAL),  zodat  FUDN  3  kan  vervallen. 

•  De  drie  veldwaarden  FULLY  OPERATIONAL,  LIMITED  OPERATIONAL  en 
NON-OPERATIONAL  onder  FUDN  2  komen  onder  FUDN  1  voor  als  OPERATIONAL, 
PARTIALLY  OPERATIONAL  en  NOT  OPERATIONAL.  Door  de  naamgeving  aan  te 
passen  kan  men  eenvoudig  drie  veldwaarden  besparen. 

•  Indien  de  waarden  AVAILABLE  en  OPERATIONAL  dezelfde  betekenis  hebben  m.b.t. 
het  veld  BED  STATUS  (het  hospital  meldt  hoeveel  bedden  beschikbaar  zijn)  dan  heeft 
het  veld  geen  enkele  toegevoegde  waarde. 

•  Het  is  niet  duidelijk  in  hoeverre  de  velden  LOSSES  (FUDN  4),  CCIS  STATUS  (FUDN  5 
en  6)  en  POSITION  (FUDN  7)  toegevoegde  waarde  hebben.  Alle  drie  de  velden  worden 
gebruikt  in  het  veld  OPERATIONAL  STATUS.  LOSSES  wordt  gebruikt  in  een  ENEMY 
CONTACT  REPORT.  CCIS  STATUS  wordt  gebruikt  in  een  CCIS  STATUS  REPORT  en 
POSITION  wordt  gebruikt  in  een  OWN/ENEMY  SITUATION  REPORT. 

•  Vier  veldwaarden  die  wcl  voorkomen  onder  FUDN  5,  te  weten:  INTERRUPTION, 
JAMMING,  OCCUPATIONAL  en  REPAIRING  komen  niet  voor  onder  FUDN  1  terwijl 
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het  waardenbereik  onder  FUDN  1  een  verzameling  lijkt  te  vormen  van  alle  mogelijke 
waaiden. 

•  Het  waardenbereik  van  het  veld  OPERATIONAL  STATUS  bevat  26  waaiden  van  zeer 
uiteenlopende  aard,  zodat  dit  veld  op  verschillende  manieren  kan  worden  gebmikt. 

Tussen  de  verschillende  gebruiksmogelijkheden  dient  te  worden  gediscrimineerd  door 
introduktie  van  een  aantal  FUDN's. 

In  het  kader  van  het  "ADSIA/NUNN  initiatief’  zijn  met  betrekking  tot  "NATO  Procedural 
Interoperability  Standards"  (NPIS)  projecten  opgestart,  waarvan  een  aantal  projecten  moeten 
resulteren  in  geautomatiseerde  ondersteuning  bij  het  ontwikkelen  van  nieuwe  ADatP-3  bericht- 
formaten  en  het  bijhouden  en  beheren  van  alle  ADatP-3  berichtformaten  en  gerelateerde 
informatie.  Door  de  geautomatiseerde  ondersteuning  kunnen  een  aantal  problemen  verholpen  of 
verminderd  worden.  Dit  geldt  voor  de  problemen  m.b.t.  de  definitie  van  elementen  van  bericht¬ 
formaten  en  in  het  bijzonder  de  consistentie  ervan. 
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3.3 

EDIFACT 

3.3.1 

Achtergrond 

Evenals  in  de  militaire  wereld  wordt  in  de  civiele  wereld  informatie  tussen  (intemationale) 
organisaties  (partners)  uitgewisseld.  Om  wildgroei  binnen  de  vele  soorten  organisaties  te 
voorltomen  zijn  begrippen,  syntaxregels  en  ook  berichten  genormaliseerd  of  in  voorbereiding 
voor  normalisatie. 

Tot  1985  bestonden  er  wereldwijd  gezien  twee  standaarden  voor  EDI,  te  weten  GTDI  (General 
Trade  Data  Interchange  rules)  van  de  Economic  Commision  of  Europe  (ECE)  en  X.12  van  het 
American  National  Standards  Institute  (ANSI).  Begin  1985  heeft  hierover  oveileg 
plaatsgevonden,  waama  in  enkele  maanden  een  EDIFACT-systeem  is  ontworpen  voor  een 
wereldwijde  normalisatie  (IS09735].  In  September  1986  namen  de  Verenigde  Naties  dit 
EDIFACT-systeem  over  en  erkenden  het  als  ISO-standaard. 

EDIFACT-standaarden  worden  voorbereid  in  de  Working  Party  4  van  UN  Economic  Commision 
of  Europe,  in  samenspraak  met  ISO  (International  Standards  Organization).  In  de  Working  Party  4 
zijn  Noord-Amerika,  en  West-  en  Oost-Europa  venegenwoordigd.  Waarschijnlijk  zullen  in  de 
nabije  toekomst  nieuwe  regio’s  deelnemen  in  het  gemeenschappelijk  overleg,  te  weten  Japan, 
Singapore,  Australia  en  Nieuw-Zeeland. 

Het  overgrote  deel  van  organisaties  heeft  aangegeven  de  EDIFACT-standaarden  te  zullen  volgen. 
Er  zijn  echter  enkele  organisaties  die  al  voor  de  totstandkoming  van  de  EDIFACT-standaarden 
eigen  berichten  ontwikkeld  hadden.  Deze  organisaties  hebben  verklaard  binnen  enkele  jaren  naar 
de  EDIFACT-standaarden  te  migreren. 

3.3.2  Berichtstructuur 

De  algemene  structuur  van  het  EDIFACT  berichtformaat  (zie  figuur  3.11)  kent  grote 
overeenkomsten  met  die  van  het  ADatP-3  berichtformaat.  Een  EDIFACT  bericht  bestaat  ook  uit 
'zinnen'  aangeduid  als  segmenten  (ADatP-3:  sets)  die  geordend  en  gegroepeerd  kunnen  zijn. 
Groepen  segmenten  kunnen  weer  genest  zijn. 

Een  segment  bestaat  uit  data  elcmentcn  die  enkelvoudig  (simple)  of  samengesteld  (composite) 
kunnen  zijn.  Een  samengesteld  data  element  bestaat  uit  data  element  componenten  (die  i.t.t. 
ADatP-3  gescheiden  zijn  d.m.v.  een  teken). 


Figuur  3.1 1; 


HiCrarchische  slnictuur  EDIFACT  Interchange 
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3.3.3  Opmerkingen 

Een  aantal  belangrijke  verschillen  met  ADatP-3  zijn; 

•  Het  gebruik/vooikomen  van  berichtonderdelen  (zinnen,  velden)  is  veiplicht  of 
conditioned,  en  dus  niet  optioneel. 

•  Hertialing  van  onderdelen  is  mogelijk,  maar  gelimiteerd  (bovengrens  gespecificeerd). 

•  Er  zijn  geen  berichtonderdelen  (zinnen)  voor  (lange  stukken)  vrije  (veiklarende)  tekst, 
wat  inhoud  dat  in  de  gedefinieerde  data-segmenten  voldoende  informatie  doorgegeven 
moet  kunnen  worden. 

•  In  een  EDIFACT  berichtenuitwisseling  kunnen  meerdere  berichten,  eventueel  verdeeld 
over  een  aantal  functionele  groepen,  tegelijk  verzonden  worden. 

•  In  een  EDIFACT  bericht  kurmen  zogenaamde  qualifiers  gebruikt  worden  om  een  enkel 
segment  meerdere  betekenissen  te  geven.  Hierdoor  kunnen  een  beperkt  aantal  segementen 
en  berichten  een  groot  doelgebied  beschrijven. 
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4.  Functionaliteit  berichtenYerwerkingssysteem 

4. 1  Inleiding 

Het  gebruik  van  FORMETS  in  een  operationele  omgeving  vereist  een  voldoende  overzicht  bij  de 
gebruiker  om  een  verstandige  selectie  te  kunnen  maken  uit  de  beschikbare  formaten.  Daamaast 
meet  de  gebmiker  goed  bekend  zijn  met  de  syntax  en  semantiek  van  een  groot  aantal  berichten. 

Volledige  kennis  van  ADatP-3  is  een  bijna  onmogelijke  opgave,  de  documentatie  bestaat  uit  5 
boekwerken  met  meer  dan  2200  bladzijden.  Er  zijn  momenteel  circa  80  (en  in  de  toekomst 
circa  2(X))  verschillende  berichttypen,  ongeveer  350  verschillende  setformaten  en  veel  meer  dan 
1(XX)  verschillende  veldformaten.  Per  veldformaat  is  het  gebruik  nog  eens  afhankelijk  van 
verschillende  toepassingen. 

In  een  operationele  omgeving  ontbreekt  het  vaak  aan  tijd  en  middelen  om  vast  te  stellen  volgens 
welk  vast  formaat  infonnatie  dient  te  worden  doorgegeven.  In  tijden  van  spuming  of  in  kritische 
situaties,  is  het  onredelijk  om  de  gebruiker  zijn  wedc  te  laten  doen  zonder  enige  voim  van 
computer  ondersteuning.  Zonder  computer  ondersteuning  is  van  een  snelle  en  correcte  preparatie 
van  uitgaande  ADatP-3  berichten  nauwelijks  sprake.  Wachttijden  lopen  hoog  op  of  men  moet 
genoegen  nemen  met  incorrect  geformatteerde  berichten. 

Voor  de  verwerking  van  binnengekomen  ADatP-3  berichten  is  de  gebruiker  net  zo  afhankelijk 
van  computer  ondersteuning.  Het  formaat  van  een  bericht  bepaald  immers  de  semantiek  van  de 
informatie,  d.w.z.  de  positie  van  een  veld  binnen  een  set  en  de  positie  van  een  set  binnen  een 
bericht  zijn  bepalend  voor  de  informatie  die  in  een  set  of  veld  ligt  opgeslagen.  Ook  bij  de 
verwerking  van  berichten  is  computer  ondersteuning  dus  noodzakelijk. 

Het  ontwerpen  van  een  berichtenverwerkingssysieem  (Engels:  Message  Handling  Systeem, 
afgekort  met  MHS)  is  het  doel  van  dit  hoofdstuk.  Eerst  worden  de  informatie  stromen  m.b.t.  de 
inkomende  en  uitgaande  berichten  geanalyseerd,  om  vervolgens  de  functionaliteit  van  een  MHS  te 
decomposeren  in  een  aantal  deelfuncties. 
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4.2  Analyse  van  de  informatie  stromen 

Analyse  van  de  berichtenstromen  is  een  goede  manier  om  de  functionaliteit  van  een  MRS  in  kaart 
te  brengen.  Men  kan  hierbij  onderscheid  maken  in  de  stroom  van  inkomende  en  de  stroom  van 
uitgaande  berichten.  Na  een  analyse  van  deze  informatiestromen  kunnen  de  diverse  stappen 
opnieuw  worden  gerangschikt  zodat  duidelijk  wordt  uit  welke  deelfuncties  een  MHS  bestaat 


4.2.1  Inkomende  berichten 

De  algemene  informatiestroom  m.b.t.  inkomende  berichten  volgt  bijvoorbeeld  het  trajekt  zoals 
aangeven  in  figuur  4.1. 


Informatiestroom  van  inkomende  berichten. 
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E>e  stappen  die  het  bericht  daarbij  doorloopt  zijn: 

•  Ontvangst  van  het  bericht: 

Een  bericht  komt  aan  bij  een  communicatie  medium. 

•  Registratie  van  het  bericht: 

Het  bericht  wordt  in  een  berichtenbestand  geplaatst,  voorzien  van  een  tijdsstempel  en  een 
statusvlag.  De  statusviag  wordt  continue  bijgewerkt  en  is  aihankelijk  van  de  bewerkingen 
die  het  bericht  ondergaat. 

•  Verificatie  van  de  envelop: 

Er  wordt  gecontroleerd  of  de  (communicatie  medium  afhankelijke)  stuuncode  (envelop) 
correct  is,  d.w.z.  of  alle  benodigde  informatie  aanwezig  en  het  adres  correct  is.  Verder 
moet  het  adres  overeen  komen  met  het  eigen  adres.  Indien  de  envelop  een  fout  bevat  of 
verkeerd  geadresseerd  blijkt  te  zijn,  dan  moet  het  bericht  opnieuw  geadresseerd  worden 
(indien  mogelijk)  of  door  een  operator  verder  worden  behandeld.  Eventueel  kan  een 
verzoek  voor  het  opnieuw  uitzenden  van  een  bericht  automatisch  worden  gegenereerd. 

•  Identificatie  van  het  berichttype: 

Indien  mogelijk,  wordt  de  berichtklasse  (b.v.  ADatP-3)  en  het  type  (b.v.  TASKORDER) 
van  het  bericht  bepaald  aan  de  hand  van  opgeslagen  berichtformaten  (b.v.  de  MTFs  van 
ADatP-3).  Als  de  klasse  en  het  type  met  van  toepassing  is  voor  de  geadresseende,  dan 
moet  wederom  actie  worden  ondemomen  naar  de  verzender. 

•  Consultatie  van  de  interne  distributielijst: 

Voor  elke  klasse  en  type  bericht  moet  de  interne  distributielijst  worden  geraadpleegd.  Er 
zijn  twee  mogelijkheden:  het  bericht  wordt  geheel  automatisch  verwerict  of  het  bericht 
wordt  (eerst)  door  een  operator  in  behandeling  genomen.  In  het  eerste  geval  geeft  de 
interne  distributie  aan  welke  geautomatiseerde  behandeling  het  bericht  moet  ondergaan, 
in  het  tweede  geval  geeft  deze  lijst  aan  welke  personen/instanties  het  bericht  moeten  zien, 
eventueel  corrigeren  en  accepteren. 

•  Distributie  van  het  bericht: 

Het  bericht  wordt  verspreid  volgens  de  interne  distributielijst  (waarbij  maximaal  1 
persoon  gemachtigd  is  om  de  gegevens  in  een  of)eraUonele  database  te  verwerken). 
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Bepaalde  berichten  kunnen  vervolgens  volledig  automatisch  worden  verwerkt,  hetgeen  over  het 
algemeen  zal  leiden  tot  een  reeks  van  updates  op  de  operationele  database.  Dit  gebeurt  in  een 
tweetal  stappen,  te  weten: 

•  Analyse  van  het  bericht: 

Het  binnengekomen  bericht  wordt,  m.b.v.  het  bestand  van  berichtfonnaten,  geanalyseerd 
en  de  informatie  die  erin  ligt  opgeslagen  wordt  opnieuw  gerangschikt. 

•  Generatie  van  database  update  statements; 

Daama  wordt  deze  voorbewerkte  informatie  omgevormd  tot  een  reeks  van  database 
update  statements,  die  doorgestuurd  voor  verwerking  in  de  operationele  database. 

Bij  een  manuele  verwerking  van  een  bericht  vinden  een  aantal  personen  (interne  distributielijst) 
het  bericht  in  hun  (persoonlijke)  postvak  (mailbox)  en  bekijken  het.  Een  daartoe  geautoriseerde 
operator  modificeert  eventueel  een  aantal  velden,  om  vervolgens  de  informatie  te  Oaten) 
verwerken  in  de  operationele  database.  De  operator  kan  een  aantal  stappen  ondememen,  te  weten: 

•  Editing  van  het  bericht: 

Het  bericht  wordt  door  een  operator  aangepast  aan  de  eisen  die  zijn  organisatie  er  aan 
stelt. 

•  Generatie  van  een  coOrdinatie  bericht; 

Bij  een  bericht  kunnen  opmerkingen  en/of  correcties  aangebracht  worden.  Het  bericht 
plus  de  opmerkingen  wordt  'terug'-gestuurd  naar  een  centraal  punt,  i.e.  een  persoon  die 
gemachtigd  is  om  het  bericht  verder  te  verwerken  (updates  in  operationele  database). 

•  Database  update: 

Op  basis  van  de  informatie  in  een  bericht  kan  een  daartoe  geautoriseerde  operator  de 
inhoud  van  de  operationele  database  wijzigen.  Voor  een  deel  kan  hij  dit  echter  ook 
automatisch  laten  uitvoeren  volgens  de  hiervoor  beschreven  methode. 
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4.2.2  Editing  van  berichten 

De  "editing"  van  een  bericht  speelt  een  rol  bij  zowel  het  verwerken  van  binnengekomen  berichten 
als  het  opsteUen  van  uitgaande  berichten.  Het  edit  proces  is  weergeven  in  figuur  4.2. 


De  stappen  die  bij  editing  een  rol  spelen  zijn: 


•  Het  ophalen  van  een  bestaand  bericht: 

Een  eerder  ontvangen  of  verzonden  bericht  (of  een  deel/delen  ervan)  of  een  bericht- 
sjabloon  moet  gebruikt  kunnen  worden  om  verder  te  gaan  met  het  verwerken  ervan  of  om 
een  nieuw  bericht  mee  aan  te  maken. 

•  Presentatie  van  het  bericht: 

Het  bericht  wordt  opgemaakt  en  aan  de  gebruiker  getoond  in  een  leesbare  vorm,  hetzij  in 
een  'ruwe'  vorm  of  op  een  wijze  met  extra  verduidelijkende  tekst  Gabels). 

•  Controle  van  het  bericht  (formaat): 

Het  bericht  wordt  syntactisch  en  semantisch  gecontroleerd,  a.d.h.v.  van  het  bestand  van 
berichtformaten. 
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•  Veld  conversie: 

De  inhoudAvaarde  van  een  veld  wordt  eventueel  geconverteerd  van  het  ene  (bericht)  in 
een  ander  (database,  presentatie)  fonnaat. 

•  Modificatie  van  het  bericht: 

Een  gebruiker  meet  op  eenvoudige  en  gestructureerde  wijze  een  berichttekst  kunnen 
invoeren  en  wijzigen,  waarbij  hij  zoveel  mogelijk  begeleid  wordL 

•  Het  verstrekken  van  help  infonnatie: 

De  gebruiker  moet  zoveel  mogelijk  help  informatie  op  kunnen  vragen  omtrent  de 
algemene  werking  van  het  systeem,  de  functies  die  tot  zijn  beschikking  staan  en  de 
verschillende  berichtformaten. 

•  Tijdelijke  ofwel  permanente  opslag  van  het  bericht: 

Het  bericht  moet  tijdens  de  verweiking/preparatie  ervan  djdelijk  opgeslagen  kunnen 
worden  om  later  verder  verwerkt  respectievelijk  gecompleteerd  te  kunnen  worden. 
Permanente  opslag  is  gewenst  voor  een  berichtsjabloon  dat  frequent  wordt  gebruikt  voor 
de  preparatie  van  berichten. 
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4.2.3  Uitgaande  berichten 

Voor  de  informatie  stroom  van  uitgaande  berichten  zijn  er  twee  mogelijkheden;  een  bericht  wordt 
volledig  automatisch  gegenereerd  en  verzonden  of  een  bericht  wordt  opgesteld  door  een  operator 
en  verzonden.  Dit  is  weergegeven  in  figuur  4.3. 


Figuur  4.3:  Informatiestroom  van  uitgaande  berichten. 

Afhankelijk  van  een  aantal  parameters  (o.a.  dc  tijd)  en  de  status  van  de  informatie  zoals  deze  ligt 
opgeslagen  in  de  operationele  database  kan  een  MHS  overgaan  tot  automatische  generatie  van 
berichten.  Het  trajekt  dat  een  bericht  dan  doorloopt,  ziet  er  als  volgt  uif. 

•  Evaluatie  van  de  operationele  situatie: 

Eerst  dient  te  worden  vastgesteld  of  er  een  gebeurtenis  heeft  plaatsgevonden 
(ovcrschreiding  van  een  bepaalde  tijdslimiet,  wijziging  van  belangrijke  database  tabellen) 
die  vc.  -tending  van  een  bepaald  type  bericht  noodzakelijk  maakt. 
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•  Database  selectie: 

Vervolgens  wordt  een  selectie  van  gegevens  uit  de  operationele  databar;  toegevoegd  aan 
een  bestaand  berichtensjabloon. 

•  Adres  generalie: 

Tenslotte  dient  bet  bericht  van  een  adres  te  worden  voorzien. 

Bij  bet  opstellen  van  een  bericbt  door  een  operator  ziet  bet  trajekt  er  beel  anders  uit: 

•  Editing  van  bet  bericbt: 

De  operator  stelt  een  bericbt  op  a.d.h.v.  de  eisen  die  eraan  worden  gesteld.  Naast  dc 
editing  zoals  bierboven  bescbreven  zijn  er  nog  cen  a^Jital  extra  stappen  die  de  operator 
ondemeemt  bij  de  preparatie  van  een  bericbt,  te  weten: 

Selectie  van  gegevens  uit  de  operationele  database: 

Een  selectie  van  gegevens  uit  de  operationele  database  wordt  verwerict  in  een 
uitgaand  bericbt. 

Adressering: 

De  personen  en/of  instanties  waamaar  bet  bericbt  gestuurd  worden 
gespecificeerd.  Het  adres  moet  een  naam  zijn  en,  indien  mogelijk,  niet  bestaan  uit 
bet  complete  (communicatie  medium  afbankelijke)  adres,  wat  later  bij  bet 
samenstellen  van  de  envelop  (stuurcode)  toegevoegd  moet  worden. 

•  Distributie  van  een  bericbt: 

Distributie  van  een  bericbt  voor  coordinatie: 

Een  aantal  personen/instanties  (interne  distributielijst)  moeten  instemmen  met  de 
inboud  van  bet  bericbt  en  eventuele  opmerkingen  aangeven. 

Distributie  van  een  bericbt  voor  autorisatie: 

Het  bericbt  moet  door  een  verzendgemacbtigde  vrijgegeven  worden. 

Distributie  van  een  bericbt  voor  verzending: 

Het  bericbt  wordt  vrijgeg'*ven  door  de  opsteller  voor  verzending  en  wordt  in  de 
wacbtrij  voor  te  verzenden  bericbten  gezet.  waarbij  voor  de  bebandeling  rekening 
wordt  gebouden  met  de  prioriteiten  van  de  bericbten. 
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Het  laatste  deel  van  het  trajekt  is  gelijk  voor  zowel  de  geautomatiseerde  als  de  manuele  preparatie 
van  berichten: 

•  Generatie  van  de  envelop: 

Voordat  een  bericht  via  een  communicatie  medium  verstuurd  kan  worden,  moet  voor  het 
betreffende  medium  stuurcode  (een  ’envelop)  gegenereerd  wonlen  met  o.a.  de  exacte 
adressen. 

•  Registratie  van  het  bericht: 

Het  bericht  wordt  in  een  berichtenbestand  geplaaist,  voorzien  van  een  tijdsstempel  en  een 
statusvlag.  De  statusvlag  is  afhankelijk  van  eventuele  terugmeldingen. 

•  Verzending  van  het  bericht: 

Het  bericht  (inclusief  envelop)  wordt  verstuurd. 
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4.3  Functionele  decompositie 

In  figuur  4.4  is  een  context  diagram  opgenomen  van  een  MHS.  Duidelijk  komen  hierin  vier 
exteme  interfaces  naar  voren,  te  weten: 

1 )  Interface  met  de  communicatie  voorziening  (CFE  functie). 

2)  Interface  met  de  gebruiker  (operator  functie). 

3)  Interface  met  de  operationele  database  (DBMS  functie). 

4)  Interface  met  de  organisatie(s)  die  de  berichtfonnaten  in  zijn/hun  beheer  hebben. 


nieuwe 

bericht 

formaten 


database  updates 


database  selecties 

DBMS 


Figuur  4.4:  Context  diagram  van  een  MHS. 


Dc  operationele  gebruiker  van  bet  MHS  zal  over  het  algemecn  ook  een  meer  directe  toegang 
hebben  tot  de  operationele  database.  Deze  interface  tussen  operator  en  DBMS  valt  buiten  de 
context  van  het  MHS  maar  is  wel  degelijk  van  belang.  De  MMI  dient  op  elkaar  te  worden 
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afgestemd  en  conflictsituaties  (directe  database  updates  versus  updates  via  het  MHS)  dient  men 
zoveel  mogelijk  te  vermijden. 

Uit  de  analyse  van  de  informatiestromen  (zie  voorgaande  paragraven)  blijkt  dat  een  MHS 
minimaal  vier  hoofdfuncties  omvat,  te  weten; 

1)  Berichten  I/O. 

2)  Operator  interface. 

3)  Database  verwerking. 

4)  Beheer  van  de  berichiformatcn. 

Veel  van  de  huidige  C^-systemen  omvatten  slechts  de  eerste  twee  hoofdfuncties.  Sommige  C^- 
systemen  zullen  daamaast  een  component  bevatten  die  berichtformaten  beheert.  VoUedig 
geautomatische  verwerking  met  een  interface  naar  de  operationele  database  is  nieuw  en  zal  zich  in 
een  nieuwe  generatie  van  C^-systemen  gaan  manifesteren. 

Het  top  level  dataflow  diagram  van  een  MHS  is  weergegeven  in  figuur  4.5.  Dit  diagram  laat  zien 
hoe  de  vier  hoofdfuncties  aan  elkaar  zijn  gerelateerd.  De  laatste  functie  m.b.t.  het  beheren  van  de 
berichtformaten  heeft  een  duidelijk  off-line  karakter,  communicatie  met  de  andere  hoofdfuncties 
verloopt  via  het  bestand  van  berichtformaten  (dat  uiteraard  wel  on-line  beschikbaar  is).  De  andere 
functies  hebben  juist  een  on-line  karakter  en  dienen  te  voldoen  aan  de  stringente  eisen  t.a.v. 
beschikbaarheid,  tijdigheid,  correctheid  en  nauwkeurigheid,  die  de  operationele  omgeving  er  aan 
sicli. 

De  operator  interface  zal  waarschijniijk  worden  geimplementeerd  op  een  (groot)  aantal 
werkstations,  terwijl  de  berichten  I/O  en  de  database  verwerking  op  6dn  of  op  twee  server 
systemen  gaan  draaien.  Eventueel  kan  de  berichten  I/O  functie  worden  geintegreerd  met  de  CFE 
functie.  Het  bestand  van  berichtformaten  dient  te  worden  gedistribueerd  over  die  systemen 
waarop  de  andere  functies  worden  gerealiseerd. 
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Figuur  4.5:  Top  level  dataflow  diagram  van  een  MHS. 


Hiema  zullen  de  vier  hoofdfunctics  in  nader  detail  worden  beschreven. 
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4.3.1  Berichten  registratie  en  distributie 

Berichten  I/O  omvat  alle  functies  die  nodig  zijn  voor  het  ontvangen,  registreren,  distribueren  en 
het  versturen  van  berichten; 

(a)  Ontvangst  van  berichten  die  binnen  komen  (via  de  CFE  processor). 

(b)  Archivering  van  alle  binnengekomen  en  uitgaande  berichten,  met  een  tijdsstempel. 

(c)  Het  initialiseren  en  bijhouden  van  de  status  van  de  geregistreerde  berichten. 

(d)  Verificatie  van  de  envelop. 

(e)  Identificatie  van  de  berichtklasse  en  het  berichttype. 

(f)  Indien  noodzakelijk  distributie  naar  een  officier  van  de  verbindingsdienst,  die  een 
controlerende  en  foutherstellende  taak  heeft. 

(g)  Het  retoumeren  aan  afzender  indien  daar  redenen  voor  bestaan. 

(h)  Het  beheer  van  de  interne  en  exteme  distributielijsten. 

(i)  Interne  distributie. 

(j)  Generatie  van  een  envelop  bij  uitgaande  berichten. 

(k)  Het  versturen  van  uitgaande  berichten  (via  de  CFE  processor). 


Figuur  4.6: 


Dataflow  diagram  van  dc  berichten  I/O  functie. 
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Bij  de  verificatie  en  generatie  van  de  bericht-envelop  moet  een  keuze  worden  gemaakt  m.b.t.  het 
protocol  (X.400  of  ACP  127)  op  de  hogere  lagen  van  bet  ISO-OSI  model.  De  CFE  functie  zorgt 
voor  de  verdere  afhandeling  van  het  bericht  op  de  onderliggende  lagen  van  het  ISO-OSI  model. 

Het  beheren  van  distributielijsten  is,  net  zoals  het  beheren  van  de  berichtformaten,  een  off-line 
functie. 

4.3.2  Interface  met  de  gebruiker 

De  functies  die  zijn  opgenomen  in  de  interface  met  de  operator,  d.w.z.  die  functies  die  de 
gebruiker  tot  de  beschikking  staan,  zijn: 

(a)  Het  opvragen  van  berichten. 

(b)  Het  presenteren  van  berichten. 

(c)  Een  syntax  controle  uitvoeren  op  de  berichten. 

(d)  Veldconversie. 

(e)  Het  wijzigen  van  berichten. 

(0  Het  verstrekken  van  help  informatie. 

(g)  Het  tijdelijk  of  pennanent  opslaan  van  berichten. 

(h)  Synthese  van  berichten  met  informatie  vanuit  verschillende  bronnen. 

(i)  Coordinate  m.b.t.  de  berichten. 

(j)  Autorisatie  van  berichten. 

(k)  Het  vrijgeven  van  berichten. 

Figuur  4.2  (zie  paragraaf  4.2.2)  geeft  een  goede  indruk  van  de  relates  tussen  de  eerste  zes 
operator  functies  (a  t/m  g).  De  resterende  functies  (h  t/m  k)  zijn  weergegeven  in  figuur  4.3  (zie 
paragraaf  4.2.3). 

Deze  interface  met  de  operator  dient  uiteraard  te  worden  afgestemd  op  andere  MMI  functes 
binnen  hetzelfde  C^-systeem.  Bij  implcmentatie  doet  men  er  goed  aan  standaards  zoals  X- 
windows  te  gebruiken. 
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4.3.3  Interface  met  de  operationele  database 

De  geautomatiseerde  verweridng  van  berichten  m.b.t.  een  operationele  database  valt  uiteen  in 
twee  delen: 

a)  Interprctatie  van  ingekomen  berichten. 

b)  Preparatie  van  uitgaande  berichten. 
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Figuur  4.7:  Dataflow  diagram  van  de  interface  met  een  operationele  database. 


4.3.3. 1  Interprctatie  berichten 

De  gegevens  in  een  ingekomen  bericht  moeten  geVnterpreteerd  worden  en  uiteindelijk  in  een 
operationele  database  verwerkt  worden.  Een  ingekomen  geformatteerd  bericht  kan  in  principe* 
geheel  op  automatische  wijze  zondcr  tussenkomst  van  een  operator  in  de  database  verwerkt 
worden.  Het  is  ook  mogelijk  dat  een  operator  de  gegevens  in  een  bericht  eerst  bekijkt  en  eventueel 
corrigeert,  waama  het  bericht  vrijgegeven  wordt  om  de  gegevens  automatisch  in  de  database  te 
verwerken. 


Niet  alle  geformalteerde  berichten  kunnen  geheel  automatisch  verwerkt  worden  vanwege  een  veelvoud  van  manieren  om  de 
gegevens  te  interpreteten  en  vanwege  de  consistentie  van  de  inhoud  van  de  operationele  database. 
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Om  de  gegevens  in  een  berichl  in  de  operationele  database  te  verweriten  dient  het  bericht  eerst  te 
worden  opgesplitst  in  elementaire  data-elementen  (zie  NIAM-diagram  'actueel  bericht').  Een  data- 
element  kan  een  veld  of  een  onderdeel  van  een  veld  (subveld)  zijn.  Per  data-element  moeten, 
behalve  de  waarde,  een  aantal  gegevens  over  de  context  bekend  zijn,  zoals  de  plaats  binnen  een 
veld,  set,  segment  (eventuele  nesting)  en  bericht  en  het  type  van  het  veldonderdeel  en  het 
omhullende  veld,  set  en  bericht. 

Het  opsplitsen  in  elementaire  data-elementen  kan  bij  de  syntactische  analyse  gedaan  worden, 
waarbij  gebruik  wordt  gemaakt  van  het  bestand  van  berichtformaten. 

Wanneer  het  bericht  opgesplitst  is,  dan  moeten  daama  de  relaties  (aanknopingspunten)  van  de 
data-elementen  met  de  database  (tabellen  en  kolommen)  bepaald  worden*,  wat  moet  uitmonden  in 
een  aantal  acties  in  de  vorm  van  SQL-statements  om  de  database  aan  te  passen.  De  relaties  van 
(elementaire)  onderdelen  van  een  berichtformaat  moeten  ook  aanwezig  zijn  in  het  bestand  van 
berichtfonmaten. 

Het  aanmaken  van  SQL-statements  kan  gebeuren  door  de  data-elementen  met  tabeVkolom 
informatie  (zie  NIAM-diagram  'veld-kolom')  te  rangschikken  en  daaruit  de  statements  te 
extraheren  of  door  het  ophalen  van  voorgedefinieerde  statement-sjablonen  (n.a.v.  een  patroon  van 
berichtonderdelen)  en  invulling  van  de  actuele  waarden  van  de  data-elementen. 

De  SQL-statements  kunnen  INSERT-  en/of  UPDATE-statements  zijn  afhankelijk  van  de  reeds  in 
de  database  opgeslagen  gegevens. 

Bij  verweiking  van  een  ingekomen  bericht  kunnen  een  drietal  problemen  optreden: 

1)  Een  data-element  kan  niet  zonder  meet  in  de  database  opgeslagen  worden:  er  moet  eerst 
een  (soms  niet  triviale)  conversie  uitgevoerd  worden. 

Het  kan  voorkomen  dat  datatypes  niet  overeenstemmen  v.w.b.  soort  en  afmeting. 
Bijvoorbeeld,  de  waarde  van  een  data-element  in  een  bericht  is  groter  Ganger)  dan  het 
database-element 

2)  Een  in  de  database  m.b.t.  de  consistcntie  verplicht  (sleutel)  data-element  is  niet  in  het 
bericht  aanwezig. 

3)  Gegevens  over  een  object  komen  niet  in  de  juiste  volgorde  aan  en/of  worden  niet  in  de 
volgorde  van  binnenkomst  (wegens  prioriteit  berichten)  verwerkt.  Ofwel,  gegevens  over 


Het  is  niet  ondenkbiar  dat  er  een  kennissysteem  nodig  is  om  de  informatie  op  de  juiste  manier  te  inteipteieren. 
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een  object  in  een  bericht  kunnen  ouder  zijn  dan  de  gegevens  over  het  object  in  de 
database.  Dit  kan  conflicten  veroorzaken.  Het  temporal  database  management  is  een 
probleem  op  zich  [TempDBM,  FEL91c]. 

Hieraan  gerelateetd  is  dat  bepaalde  typen  berichten,  die  tot  doel  hebben  correcties  uit  te 
voeren  op  eerder  verzonden  berichten.  'verouderde'  gegevens  bevatten:  gegevens  uit  het  te 
corrigeren  bericht  zijn  reeds  in  de  operationele  database  verwerkt  en  inmiddels  weer 
gewijzigd.  Indien  een  te  corrigeren  bericht  nog  niet  in  de  database  is  verwerkt,  dan  kan  de 
berichttekst  gewijzigd  worden  en  kan  het  gecorrigeerde  bericht  'normaal'  behandeld 
worden. 

Andere  (meer  algemene)  aandachtspunten  zijn  dat  bij  wijziging  van  gegevens  in  de  database 
gebruikers,  die  dezelfde  (soort)  gegevens  aan  het  verwerken/bekijken  zijn,  dienen  te  worden 
gewaarschuwd  (terminal  update  warning)  [FEL92]  en  dat  gelijktijdige  wijziging  van  dezelfde 
(soort)  gegevens  door  verschillende  gebruikers  (zowel  mens  als  applicatie)  inconsistenties  kunnen 
veroorzaken.  Het  laatste  kan  vaak  door  een  DBMS  afgehandeld  worden  Oocking  mechanisme), 
terwijl  het  eerste  (nog)  niet  door  een  DBMS  kan  worden  afgehandeld*. 

4.3.3.2  Preparatie  berichten 

Bij  het  prepareren  van  een  bericht  moeten  gegevens  uit  de  operationele  database  in  een  bericht 
verweikt  worden.  Dit  moet  op  automatische  en  semi-automatische  wijze  kunnen  gebeuren. 

Bij  het  op  automatische  wijze  genereren  van  een  bericht  moeten  voor  het  aan  te  maken  bericht- 
type  relaties  tussen  de  data-elementen  in  het  berichttype  en  database-elementen  en  selectie-criteria 
gedefinieerd  zijn  die  reeds  ingevuld  of  automatisch  in  te  vullen  zijn.  Op  basis  hiervan  moeten 
selectie-opdrachten  in  de  vorm  van  (SQL)  SELECT-statements  aangemaakt  worden  t.b.v.  het 
ophalen  van  gegevens  uit  de  operationele  database  en  de  invulling  van  het  bericht.  Mogelijk 
kunnen  de  data-element  relaties  en  selectie-criteria  bestaan  uit  statement-sjablonen  die 
gci'nstantieerd  dienen  te  worden. 

Het  uitvoeren  van  de  selectie-opdrachten  levert  een  hoevcelhcid  gegevens  (data-elementen)  op. 
Deze  data-elementen  moeten  dan  gerangschikt  en  op  de  juiste  wijze  geconcateneerd  worden  om 
zodoende  een  (syntactisch  en  semantisch)  correct  geformatteerd  bericht  te  vormen. 


In  dit  kader  woidt  momenieel  de  opdracht  A92KLu605  (Temiinal  Update  Systcem  in  4GL)  door  FEL-TNO  uitgevoerd. 
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Bij  het  op  semi-automatische  wijze  prepareren  van  een  bericht  tnoeten  op  verzoek  van  degene  die 
het  bericht  handmatig  aanmaakt  gegevens  voor  een  onderdeel  (set)  van  het  bericht  uit  de  database 
opgehaald  worden.  Voor  een  dergelijk  onderdeel  moeten  dan  een  selectie-opdracht  aangemaakt 
worden  met  eventuele  (door  de  operator  in  te  vullen  of  automatisch  uit  de  context  af  te  leiden) 
selectie-criteria  daarin  verweikt. 

Het  is  ook  mogelijk  dat  bij  het  handmatig  prepareren  van  een  bericht  vaste  onderdelen 
automatisch  ingevuld  worden  met  gegevens  uit  de  operationele  database. 

Bij  het  genereren  van  een  bericht  kurmen,  evenals  bij  het  verwerken  van  ingekomen  berichten, 
een  aantal  problemen  optreden: 

•  Een  data-element  uit  de  database  kan  niet  zonder  meer  in  een  bericht  gebruikt  worden:  er 
moet  eerst  een  (soms  niet  triviale)  conversie  uitgevoerd  worden. 

Dit  is  hetzelfde  probleem  als  bij  de  verwerking  van  ingkomen  berichten. 

•  Een  in  een  bericht  verplicht  (sleutel)  data-element  is  niet  in  de  database  aanwezig. 

4. 3. 3. 3  Structuur  van  de  operationele  database 

De  operationele  database  bevat  alle  informatie  die  van  belang  is  voor  de  operationele 
taakuitvoering.  Het  is  de  enige  gecentraliseerde  bron  van  informatie  waaruit  alle  gebruikers 
kunnen  putten.  De  structuur  van  de  database  zal  niet  altijd  aansluiten  bij  de  structuur  van  de 
berichten  omdat  er  andere  objecten  de  structuur  van  de  database  kunnen  beinvloeden. 

De  structuur  (data  model)  die  ten  grondslag  ligt  aan  ADatP-3  berichten  is  niet  geheel  relationeel 
waardoor  ADatP-3  berichten  niet  goed  aansluiten  op  de  momenteel  veel  gebruikte  lelationele 
RBMSs.  Vanuit  operationele  behoefiie  kurmen  'rare'  constructies  van  berichtformaten  gedefinieeid 
worden  die  echter  wel  aan  de  ADatP-3  syntax  voldoen. 

Een  voorbeeld  hiervan  is  het  uitsplitsen  van  gegevens  over  objecten  in  2  of  meer  setformaten.  Dit 
is  alleen  maar  bedoeld  voor  presentatie  doeleinden  m.b.v.  tabellarische  sets  (zie  figuur  4.8). 

De  verweiking  van  op  deze  wijze  gestructureerde  gegevens  is  niet  onmogelijk,  maar  wel  complex. 
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ADatP-3: 

6SHIP 

/DE 

/REF  /SID/QTY  /SHPTYP 

/HULL 

/TG 

/01 

/WSA304 /FRD/  1/TNK 

/- 

/2 

/02 

/WSA304/HOS/  1/KRESTA 

/- 

/I// 

7SHIP 

/DE 

/TIMPOS  /SHIPLOC 

/CRS/SPD 

/01 

/150930Z  /320-COVIA-100 

/330/ 

12KTS 

/02 

/150930Z  /350-COVIA-130 

/270/ 

10KTS// 

DB  table: 

SHIP  (DE, REF, SID, QTY.SHPTYP, HULL. TG,TIMPOS,SHIPLOC,CRS,SPD) 

SHIP  (01  ,WSA304.FRD.1  .TNK.null.2.150930Z,320-COVIA-100,330,12KTS) 
SHIP(02,WSA304,HOS,1,KRESTA,null,1.150930Z,350-COVIA-130.270,10KTS) 


Figuur  4.8:  Voorbeeld  uitsplitsing  data  over  2  sets. 


Een  ander  voorbeeld  van  het  niet  goed  aansluiten  van  de  stnictuur  van  een  berichtonderdeel  op  de 
database  wordt  getoond  in  figuur  4.9.  Hierbij  wordt  de  informatie  voor  een  lijnobject 
gespecificeerd  als  een  eerste  posilie  en  een  of  meer  volgende  posiiies,  terwijl  in  de  database  tabel 
een  aantal  rijen  met  een  positie  kan  worden  opgenomen. 


ADatP-3: 

MLINE/SERNR/FIRSTPOSTSUBSEQPOS// 
DB  table: 

MLINE  (SERNR.POS) 


Figuur  4.9:  Voorbeeld  niet  aansluiten  structuren. 


Met  het  voorgaande  is  getracht  om  een  ondergrens  voor  het  aantal  te  vermelden  posities  aan  te 
geven.  Er  zou  in  ADalP-3  een  mogclijkheid  moeten  zijn  om  een  ondergrens  (en  eventueel  een 
bovengrens)  te  stellen  voor  het  aantal  hcrhalingen  van  een  onderdeel  (veld,  groep  van  velden,  set, 
segment). 
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4.3.4  Beheer  van  de  MTF  database 

Omdat  commandovoering  binnen  de  NATO  onderhevig  is  aan  verandering,  wordt  ook  de 
berichtgeving  bijgesteld  aan  nieuwe  eisen.  De  bijstelling  van  berichtformaten  dient  zorgvuldig  te 
worden  uitgevoerd  omuat  anders  de  interoperabiliteit  in  gevaar  komt  Zowel  op  NATO  niveau  als 
op  nationaal  niveau  zijn  er  dan  ook  regelgevende  instanties  op  dit  gebied.  Deze  instanties 
distribueren  nieuwe  berichtformaten  over  de  C^-systemen  die  ermee  moeten  gaan  weiken.  De 
nieuwe  berichtformaten  komen  dan  binnen  bij  het  MHS. 

Met  beheer  van  de  berichtformaten  binnen  een  MHS  moet  op  de  eerste  plaats  gericht  zijn  op  het 
waarborgen  van  de  integriteit  van  het  besiand  aan  berichtformaten.  Men  kan  de  volgende 
subfuncties  onderscheiden: 

(a)  Het  inlezen  van  nieuwe  berichtformaten. 

(b)  Het  vervangen  van  bestaande  berichtformaten. 

(c)  Het  aan  het  bestand  toevoegen  van  nieuwe  berichtformaten. 

(d)  Het  uit  het  bestand  verwijderen  van  verouderde  berichtformaten. 

(e)  Het  toevoegen  van  help  informatie  omtrent  de  berichtformaten. 

(f)  Het  uitvoeren  van  een  strikt  configuratiebeheer. 

(g)  Het  distribueren  van  nieuwe  versies  van  het  bestand  over  de  andere  functies  van  het 
MHS. 

Distributie  van  nieuwe  versies  van  het  bestand  dient  te  worden  uitgevoerd  op  een  van  tevoren 
afgesproken  moment.  ledeneen  moet  op  hetzelfde  tijdstip  gaan  werken  met  de  nieuwe  formaten 
anders  kan  men  elkaar  niet  meer  "verstaan".  Binnenkomende  berichten  die  nog  volgens  een  oud 
berichtformaat  zijn  gefomatteerd  voldoen  per  definitie  niet  aan  de  syntax  controle  en  moeten 
eerst  worden  aangepast  alvorens  zij  alsnog  kunnen  worden  verwerkt. 
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5.  Evaluatie  bestaande  systemen 

5.1  Inleiding 

Op  het  ogenblik  zijn  er  een  aantal  hulpmiddelen  die  de  gebruiker  ondersteuning  bieden  bij  het 
verweiken  van  geformatteerde  berichten.  Binnen  het  project  zijn  een  tweetal  van  deze 
hulpmiddelen  onderzocht,  JAMPS  en  IRIS. 

5.2  JAMPS 

Het  JINTACCS  (Joint  Interoperability  of  Tactical  Command  and  Control  Systems)  Automated 
Message  Preparation  System  (JAMPS)  is  een  systeem  dat  een  aantal  geautomatiseerde 
hulpmiddelen  bevat  voor  de  preparatie  van  berichten  volgens  United  States  Message  Text  Format 
(USMTF).  Het  bevat  faciliteiten  voor  het  cregren,  aanpassen  en  verzenden  van  USMTF  berichten. 
Het  'verzenden'  gebeurt  via  berichten  aangemaakt  op  schijf  voor  (echte)  verzending  over 
communicatielijnen  of  via  op  een  printer  afgedrukte  berichten.  JAMPS  bevat  geen  faciliteiten 
voor  de  interpretatie  van  een  ingekomen  bericht. 

Het  gegvalueerde  systeem  werkt  op  een  PC  met  het  MS-DOS  besturingssysteem.  In  de 
documentatie  is  vermeld  dat  het  systeem  ook  weiict  op  workstations  met  het  Ultrix  besturings¬ 
systeem.  Over  de  workstation  versie  is  geen  informatie  bekend. 

Bij  de  evaluatie  is  de  meeste  aandacht  geschonken  aan  de  preparatie  van  berichten  en  niet  aan  de 
mogelijkheden  om  berichten  te  verzenden.  Meer  informatie  m.b.t.  de  communicatie-interface  is  te 
vinden  in  "JAMPS  User's  Manual"  (JAMPS). 

De  geformatteerde  berichten  die  m.b.v.  JAMPS  aangemaakt  kunnen  worden  zijn  gebaseerd  op 
USMTF.  USMTF  is  een  (US)  standaard  die  te  vergelijken  is  met  de  (NATO)  standaard  ADatP-3. 
Het  aanmaken  van  berichten  gebeurt  m.b.v.  voorgedefmigerde  'message  templates',  die 
opgeslagen  zijn  in  een  (eigen)  database.  Alle  velden  in  een  'message  template'  moeten  handmatig 
ingevoerd  worden.  Er  bestaat  in  de  gegvalueerde  versie  van  JAMPS  geen  mogelijkheid  om 
gcgevens  uit  een  operationcle  database  direkt  te  betrekken  bij  de  preparatie  van  een  bericht.  Voor 
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sommige  velden  kan  wel  een  keuze  gemaakt  worden  uit  beschikbare  (standaard)  codes  en  voor 
adressen  bestaat  een  mogelijkheid  om  deze  vtoraf  te  definigren  en  te  hergebniiken. 

Het  invoeren  van  gegevens  (velden)  gebeurt  in  de  'mask  mode',  waarbij  de  berichtstructuur  is 
weergegeven  en  veld  voor  veld  ingevuld  kan  worden,  of  in  de  'conversation  mode',  waarbij  de 
berichtstructuur  niet  is  weergegeven  maar  voor  het  huidige  in  te  vuUen  veld  de  formatterings 
regels  zijn  weergegeven.  In  de  'mask  mode'  is  het  ook  mogelijk  om  sets  te  manipuleren,  d.w.z. 
toevoegen  en  verwijderen  van  sets.  Tijdens  de  'mask  mode'  is  ook  de  'help  mode'  mogelijk.  Dit  is 
een  tijdelijke  'conversation  mode'.  Extra  functionaliteit  is  de  'window  mode',  waarbij,  indien  van 
toepassing,  een  tekstverwcrker  voor  vrije  tekst  velden  automatisch  wordt  geopend  en  een  pop-up 
menu  voor  beschikbare  (standaard)  veldcodes  en  veld  aliematieven  verschijnt. 

Bij  het  invoeren  van  een  veld  is  een  'masker'  weergegeven  met  de  legale  karakters  voor  een 
karakterpositie.  Na  invoering  van  een  veld  wordt  de  inhoud  gevalideerd  op  legale  karakters  en  een 
legale  waarde,  indien  van  toepassing. 

Nadat  gegevens  zijn  ingevoerd,  kan  een  berichi  opgeslagen  worden  en  kJaar  gemaakt  voor 
verzending. 

JAMPS  bevat  een  Trainer  voor  de  beginnende  JAMPS  gebn.’.iker. 

JAMPS  bevat  geen  faciliteiten  om  een  bericht  te  definigren. 

Het  is  de  bedoeling  dat  JAMPS  (of  de  functionaliteit)  onderdeel  gaat  uitmaken  van  JMAPS  (Joint 
Message  Analysis  and  Processing  System),  een  door  Mitre  te  ontwikkelen  systeem  dat  ook 
functionaliteit  bezit  om  ingekomen  bcrichten  te  analyseren,  gegevens  uii  de  ingtkomen  berichten 
op  te  slaan  in  een  operationele  database  en  gegevens  uii  een  operationele  database  te  gebruiken  bij 
de  preparatie  van  te  verzenden  berichten. 
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5.3  IRIS 

IRIS  bestaat  uit  twee  fysiek  gescheiden  deelsystemen:  een  Message  Definition  System  (DEF)  en 
een  Message  Formating  System  (MFS).  IRIS/MFS  kan  ieder  berichtformaat  behandelen  dat  met 
IRIS/DEF  is  aangemaakt. 

De  evaluatie  is  gebaseerd  op  de  beschrijving  vaii  de  fimctionaliteit  van  IRIS  zoals  die  is 
opgenomen  in  de  gebruikershandleidingen  voor  IRIS/DEF  [IRISDEF]  en  IRIS/MFS  [IRISM^  3]. 
Het  systeem  is  slechts  gedeeltelijk  (een  deel  van  IRIS/DEF)  werkend  gezien  omdat  te  gebruiken 
functietoetsen  niet  in  de  handleiding  waren  beschreven  en  omdat  het  laden  van  een  meegeleverde 
testdatabase  niet  lukte  (in  IRIS/MFS). 

5.3. 1  IRIS/DEF 

IRIS/DEF  biedt  de  mogelijkheid  om  klassen  van  structuren  en  formaten  van  berichten  te 
definigren.  Een  voorbeeld  van  een  klasse  van  geformatieerde  berichten  is  de  klasse  van  ADatP-3 
berichtformaten.  Er  kunnen  ook  andere  klassen  van  berichtformaten  gedefinieerd  worden.  De 
bcrichtformaten  moeien  dan  echtcr  wel  voldoen  aan  een  syntax  die  overeenkomt  met  de  ADatP-3 
syntax.  Dii  kan  een  belangrijke  bepcrking  zijn. 

Voor  een  (geformatteerde)  klasse  moeien  de  volgende  gegevens  vastgelegd  worden  (de  waarden 
tusscn  haken  bij  elk  gegeven  zijn  de  waarden  voor  de  ADatP-3  klasse): 

lengte  rcgel  (69). 

EndOfSet  marker  ('//'). 
field  marker  (7). 

bereik  identificaties  voor  elementaire  velden  (1000-1999). 
bereik  identificaties  voor  samengestelde  velden  (2000-2999). 
gemeenschappelijke  sets  (EXER,  OPER,  MSGID,  REF). 

Het  definiercn  van  een  berichtformaat  is  een  bottom-up  proces.  Een  bericht  moet  opgebouwd 
worden  uit  reeds  gedefinieerde  onderdelen.  Indien  een  niet  bekend  onderdeel  wordt  gebruikt,  dan 
moet  dat  onderdeel  eerst  gedefinieerd  worden  voordat  de  definitie  op  het  hogere  niveau  afgesloten 
kan  worden. 

Voor  een  berichtformaat  worden  dc  sets  en  begin  en  eindpunten  van  segmenten  waaruit  het 
bcricht  kan  bestaan  vastgelegd.  Tevens  wordt  de  volgorde  waarin  de  onderdelen  voorkomen 
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vastgelegd.  Voor  elke  set  wordt  vastgelegd  of  hei  gebmik  verplicht,  conditioned  of  optioneel  is. 
Indien  het  gebruik  conditioneel  is  kan  een  conditie  ingevoerd  worden.  Er  zijn  maar  twee 
mogelijke  soorten  condities: 

1 .  Uitsluiten  in  het  geval  dat  set  X  aanwezig  is. 

2.  Verplicht  in  het  geval  dat  set  X  aanwezig  is. 

Voor  een  set  kan  ook  vastgelegd  worden  of  deze  binnen  het  berichtformaat  heihaald  mag  worden. 
Voor  een  berichtformaat  moeten  ook  de  versie  en  de  versie-datum  opgegeven  worden.  Van  een 
berichtformaat  kunnen  verschillende  versies  tegelijkertijd  in  het  (DEF)  systeem  opgeslagen  zijn  in 
de  Central  Electronic  Message  Catalogue  (CEMC). 

Bij  de  defmitie  van  een  set  worden  de  velden,  hun  altematieve  inhouden  en  de  volgorde  van  de 
velden  vastgelegd.  Voor  elk  veld  kan  opgegeven  worden  of  het  gebruik  verplicht  of  optioneel  is. 
Er  dient  te  worden  opgemerkt  dat  het  hier  in  tegenstelling  tot  het  berichmiveau  niet  mogelijk  is 
om  condities  in  te  voeren. 

Wanneer  de  velden  van  de  set  zijn  vastgelegd,  moei  een  schemiindeling  gemaakt  (ontworpen) 
worden  voor  weergave  en  invoer  van  de  actuele  set  inhoud.  Dit  gebeurt  met  de  zogenaamde  'panel 
painter'. 

Voor  de  naamgeving  van  sets  is  een  conventie  gedefmieerd  voor  het  onderscheid  tussen  lineaire 
en  kolommen  sets.  Deze  conventie  is  gebaseerd  op  die  in  ADatP-3:  de  naam  van  een  kolommen 
set  moet  met  een  cijfer  beginnen.  Voor  de  velden  in  een  kolommen  set  moeten  ook  de  start 
positie,  de  header  en  de  uiUijning  vastgelegd  worden. 

Bij  de  definitie  van  een  veld  moeten  de  minimale  en  maximale  lengte  en  de  toegestane  karakters 
vastgelegd  worden.  Voor  samengestelde  velden,  waarvan  het  bereik  van  de  identificatie  is 
vastgelegd  bij  de  klasse-definitie,  moeten  de  onderdelen  vastgelegd  worden. 

Voor  ieder  veld  moeten  ook  de  mogelijke  gebruiksaanduidingen  (naam  en  nummer)  en  de 
mogelijke  waarden  cq.  het  waardenbcreik  worden  vastgelegd. 

De  bestaande  berichtformaten  kunnen  worden  gemodificeerd  zonder  dat  dit  resulteeit  in  een 
aanpassing  van  de  applicatie  programmatuur  (=  IRIS/MFS). 

Het  is  in  IRIS/DEF  ook  mogelijk  om  headers  met  communicatie  procedures  (b.v.  ACP  127)  te 
definieren. 
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Berichiformaten  en  communicatie  procedures  kunnen  verspreid  worden  naar  de  gebruikers  m.b.v. 
een  mission  file.  Voor  verschillende  doelgroepen  van  gebruikers  kunnen  verschillende  mallen 
(templates)  aangemaakt  worden  waarin  die  berichtformaten  zijn  opgenomen  die  gebruikt  kunnen 
worden  door  een  doelgroep.  Een  mission  file  kan  gegenereerd  worden  wanneer  er  nieuwe  versies 
van  berichtformaten  (en/of  communicatie  procedures)  gedefinieerd  zijn  die  naar  de  gebruikers 
verspreid  moeten  worden. 

IRIS/DEF  bevat  ook  nog  de  mogelijkheid  om  een  aantal  rapporten  te  genereren  m.b.t.  versie- 
beheer,  gevolgen  van  wijzigingen,  distributie  en  de  (interne)  database. 

5.3.2  IRIS/MFS 

De  belangrijkste  functionaliteit  van  IRIS/MFS  bestaal  uit  de  mogelijkheid  voor  het  prepaneren  van 
geformatteeide  en  gestructureerde  berichten. 

Bij  de  preparatie  van  een  nieuw  bericht  moet  allereerst  het  type  geselecteerd  worden.  Hiema  kan 
uit  een  menu  van  sets  beschikbaar  voor  het  geselecteerde  Message  Text  Format  (MTF)  een  set 
geselecteerd  worden  en  kunnen  de  attributen  van  de  set  van  een  waarde  voorzien  worden.  De 
volgorde  waarin  de  sets  mogen  verschijnen  is  gedefinieerd  m.b.v.  regels  voor  het  MTF  in  de 
Local  Electronic  Message  Catalogue  (LEMC).  Het  systeem  test  of  een  geselecteerde  set  in  de 
huidige  context  geplaatst  kan/mag  worden.  Het  invuUen  van  de  velden  van  een  set  geschiedt 
m.b.v.  een  (in  IRIS/DEF  ontworpen)  invoervenster  (een  ’formulier’).  De  invoer  voor  een  veld 
wordt  door  het  systeem  gevalideerd  (legale  kaiukters  en  waarde).  Er  is  een  helpfunctie  aanwezig 
die  extra  informatie  verschaft  over  de  huidige  sei/veld. 

Na  het  invoeren  van  de  hoofdtekst  van  het  bericht  kan  de  transmission  header  geprepareerd 
worden.  Hierbij  moeten  ook  de  (actie  en  info)  geadresseerden  en  bijbehorende  routing  indicators 
ingevoerd  worden. 

Een  (gedeeltelijk)  geprepareerd  bericht  kan  in  het  systeem  opgeslagen  worden.  Een  bericht  kan  te 
alien  tijde  in  de  message  library  worden  opgeslagen  voor  verdere  verwerking.  Een  andere 
opslagplaats  is  de  outtray.  Hierin  kunnen  alleen  gevalideerde  berichten  opgeslagen  worden  voor 
vcrzcnding.  Echter,  ook  niet  corrccie  berichten  kunnen  op  aangeven  van  de  gebruiker  'geforceerd' 
worden  opgeslagen  in  de  outtray. 

ten  m  de  message  library  opgeslagen  bericht  kan  wcer  worden  geladen  voor  wijziging  en/of 
toevoeging  van  data.  In  update  mode  kan  cen  set  geselecteerd  worden  waama  de  gegevens  in  set 
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gewijzigd  kunnen  worden  (m.b.v.  invoervenster),  de  set  verwijderd  kan  worden  of  een  andere  set 
tussengevoegd  kan  worden.  In  de  append  mode  kunnen  sets  aan  het  eind  van  het  bericht 
toegevoegd  worden.  Bij  het  wijzigen  worden  de  regels  voor  het  MTF,  zoals  opgeslagen  in  de 
LEMC,  in  acht  genomen. 

Een  geprepareerd  bericht  kan  gelezen  worden  door  gebruik  te  maken  van  een  fiinctionaliteit  die 
de  individuele  sets  op  een  meer  leesbare  wijze  presenteert  (m.b.v.  'invoervenster').  Een  bericht 
kan  ook  op  een  printer  afgedrukt  worden. 

Bij  het  prepareren  van  een  bericht  kan  om  het  prepareren  sneller  en  eenvoudiger  le  maken  gebruik 
worden  gemaakt  van  voorgedefinieerde  sets  waarin  reeds  een  aantal  (of  alle)  velden  zijn  ingevuld. 
Bij  het  toevoegen  van  een  set  kan  de  gebruiker  dan  of  een  'lege'  set  gebniiken  of  een  set  met 
waarden  (set  values),  indien  gedefinieerd. 

In  IRIS/MFS  is  ook  de  mogelijkheid  aanwezig  om  een  bericht  te  laden  van  een  medium  (t^, 
floppy  disk,  hard  disk)  en  op  te  slaan  in  de  intray.  Een  dergelijk  bericht  kan  gevalideerd  worden. 
De  gebruiker  moet  na  het  bekijken  van  de  ruwe  bericht  tekst  bepalen  wat  het  type  van  het  bericht 
is  aan  de  hand  van  de  MSGID  set  en  dit  type  selecteren  uit  de  bekende  MTFs.  Het  systeem 
probcert  dan  zoveel  mogelijk  sets  (regels)  in  het  bericht  te  herkennen  en  valideren  volgens  de 
regels  voor  het  geselecteerde  MTF.  Het  herkende  en  gevalideerde  deel  van  het  bericht  (in  ieder 
geval  zonder  de  header)  kan  opgeslagen  worden  in  de  message  library.  Van  het  herkende  deel 
kunnen  de  sets  ook  in  een  meer  leesbare  vorm  gepresenteerd  worden  m.b.v.  de  'invoervensters'. 

In  het  systeem  kan  een  nieuwe  mission  file  met  nieuwe  en  gewijzigde  (en  ook  ongewijzigde) 
berichtformaten  en  communicatie  procedures  worden  geVmporteerd.  De  mission  file  bevat  alle 
berichtformaten  en  communicatie  procedures  die  voor  de  betreffende  gebruiker  van  belang  zijn. 
De  LEMC  wordt  dan  opnieuw  geconfigureerd:  alle  berichtformaten  en  communicatie  procedures 
worden  vervangen.  Het  laden  van  een  nieuwe  mission  file  heeft  tot  gevolg  dat  reeds  gevalideerde 
bcrichten  in  de  message  library  in  de  intray  geplaatst  worden  om  ze  opnieuw  door  de  gebruiker  te 
laten  valideren  volgens  de  nieuwe  regels.  Een  ander  gevolg  is  dat  de  voorgedefinieerde  sets  met 
waarden  (set  values)  verwijderd  worden  en  dus  opnieuw  door  de  gebruiker  gedefinieerd  moeten 
worden. 
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5.3.3  Algemeen  IRIS 

E)e  gefivalueerde  versie  van  IRIS  draait  op  een  standaard  PC  met  het  MS-DOS  operating  systeem. 
Er  is  inmiddels  ook  een  implementatie  onder  UNIX. 

Onder  UNIX  wordt  ook  een  ADatP-3  gateway  ontwikkeld,  zoals  ook  vaak  gebruikt  wordt  bij 
civiele  EDI.  Met  deze  gateway  is  men  in  staat  om  ADatP-3  berichten  te  converteren  naar  platte 
ASCII  flies  en  vice  versa.  De  mogelijkheid  voor  bestaande  applicaties  om  gebmik  te  gaan  maken 
van  IRIS  wordt  hierdoor  groter. 

Een  andere  geplande  ftinctionaliteit  betreft  de  uitbreiding  met  een  SQL  interface.  Met  deze 
interface  is  men  in  staat  om  IRIS  koppelen  aan  een  operationele  database.  Uitgaande  berichten 
kan  men  dan  grotendeels  samenstellen  m.b.v.  de  informatie  die  aanwezig  is  binnen  deze  database 
en  binnenkomende  berichten  resulteren  in  updates  voor  de  database.  De  mogelijkheid  om  een 
bestaand  bericht  te  interpreteren  en  berichtonderdelen  op  te  slaan  binnen  een  ORACLE  database 
is  al  eerder  aangetoond  (beweert  SYSTEMATIC). 

Een  ander  systeem,  ook  ontwikkeld  door  SYSTEMATIC  en  gebaseerd  op  de  UNIX  versie  van 
IRIS,  bevat  een  (SQL)  interface  met  een  operationele  database  en  uitgebreide  berichten- 
verwerkingsfaciliteiten.  Dit  systeem  (AMH)  wordt  besproken  in  hoofdstuk  6. 

Het  IRIS  systeem  is  niet  alleen  verkrijgbaar  als  afgerond  produkt  maar  ook  als  een  Ada  applicatie 
bibliolheck.  In  deze  vorm  kan  IRIS  worden  geintegreerd  met  bestaande/geplande  systemen  die 
ook  m.b.v.  Ada  zijn/worden  ontwikkeld.  Deze  applicatie  bibliotheek  bestaat  uil  een  aantal  Ada 
packages  die  alle  faciliteitcn  (bouwsienen)  bieden  voor  het  prepareren,  het  verwerkcn  en  het 
aanpassen  van  geformateerde  en  gestructureerde  berichten  volgens  de  regels  die  zijn  opgeslagen 
in  de  Local  Electronic  Message  Catalogue  (LEMC).  Mel  behulp  van  de  basis  bouwstenen  kan  een 
eigen  systeem  ontwikkeld  worden. 
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6.  Ontwikkeling  AMH  (ADSIA/NUNN  project  6) 

6. 1  Beschrijving  AMH 

In  het  kader  van  het  "ADSIA/NUNN  initiatief  m.b.t.  NPIS  zijn  een  aantal  projeaen  opgestart, 
waarvan  er  66n  (Project  6:  Automated  Message  Handler  (AMH))  gericht  is  op  het  verbeteren  van 
de  preparatie  en  interpretatie  van  Message  Text  Formats.  Voor  dit  project  wordt  een  systeem 
ontwikkeld  door  het  Deense  Systematic,  dat  reeds  eerder  het  IRIS  systeem  (zie  vorige  hoofdstuk) 
heeft  ontwikkeld.  met  bijdrage  van  het  Amerikaanse  Mitre  v.w.b.  de  interface  met  de  operationele 
d-tCuciSC.  De  te  ontwikkelen  AMH  is  gebaseerd  op  de  UNIX  versie  van  IRIS. 

Het  doel  van  de  AMH  is  het  leveren  van  software  die; 

•  onafhankelijk  (stand-alone)  kan  werken  en  gebruikers  op  verschillende  niveaus  kan 
ondersteunen  door  faciliteiten  te  bieden  voor  het  lezen,  interpreteren  en  prepareren  van 
berichten,  die  geformatteerd  zijn  volgens  ADatP-3  regels,  zoals  bijvoorbeeld  de  volgende 
ftinctionaliteit: 

eenvoudige  berichtsamensteliing  door  een  gebruiker, 
automatische  berichtsamensteliing; 

het  automatisch  aanbrengen  van  wijzigingen  in  (andere)  geautomatiseerde 
systemen; 

validatie  van  gebruikers  invoer  volgens  de  betreffende  regels; 

syntax  check; 

hulpfaciliteiten; 

•  toestaat  om  nieuwe  of  gewijzigde  (ADatP-3)  bericht,  set  en  veld  formaten  te  introduceren 
zonder  te  herprogrammeren  (berichtformaat  beh.jer  en  wijziging); 

•  gegevens  overbrengt  en/of  ovemeemt  naar/van  andere  geautomatiseerde  systemen 
anafhankelijk  van  verdere  verwerking; 

•  overdraagbaar  is; 

•  in  andere  systemen  geVntegreerd  kan  worden. 
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Een  nadere  beschrijving  van  de  eisen  voor  een  AMH  en  de  specificatie  van  het  te  ontwikkelen 
AMH  prototype  staan  beschreven  in  resp.  "User  Requirement  AMH"  [AMH91a]  en  "Automated 
Message  Handler  System  Definition  and  Specification"  [AMH91b]. 

Het  te  ontwikkelen  systeem  valt  (evenals  IRIS)  uiteen  in  twee  delen,  en  wel  AMH/DEF  (berichten 
defmitie  systeem)  en  AMH/MFS  (berichten  verwerking  systeem).  Tevens  komen  applicatie 
bibliotheken  beschikbaar  die  de  bouwstenen  voor  de  AMH/MFS  of  een  eigen  te  ontwikkelen 
berichtenverwerkingssysteem  bevatten. 

De  functionaliteit  van  AMH/DEF  (berichtformaat  beheer)  kan  als  volgt  samengevat  worden: 

•  Inlezen  van  berichtformaten  die  centraal  (ADSIA)  ontwikkeld  en  overeengekomen  zijn. 

•  Verwerking  van  berichtformaten: 

+  Invoer  van  een  nieuw  (eigen)  formaat. 

+  Wijziging  van  een  formaat. 

+  Vcrwijdering  van  een  formaat. 

+  Invoeren/inlezen  van  parameters  voor  database  acquisitie. 

•  Verspreiding  benchtformaten  naar  de  betreffende  gebruikers. 

•  Uitvoeren  van  configuratie  checks  en  status  overzicht  van  berichtformaten. 

De  functionaliteit  van  AMH/MFS  (berichtenverwerking)  kan  als  volgt  samengevat  worden: 

•  Inlezen  berichtformaten  (afkomstig  van  defmitie  systeem)  in  het  berichtenverweildngs- 
systeem. 

•  Preparatie  van  berichten: 

+  Handmatige  preparatie. 

+  Automatische  preparatie. 

+  Preparatie  berichtkop  (envelop). 

+  Versturen  bericht. 
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•  Verwerking  van  inkomende  berichten: 

+  Acceptatie  bericht. 

+  Check  berichttekst. 

+  Corrcctie  berichttekst. 

+  Distributie  (intern)  bericht. 

+  Venveridng  infonnatie  (in  database). 

•  Ondersteuning  verweridng: 

+  Bijhouden  tijdschema. 

+  Zoeken  naar  bepaalde  berichten. 

+  Bijhouden  (inteme/exteme)  distributielijsten. 

+  Weergave  bericht  in  uitgebrcide  versie. 

+  Administratie  berichten. 

6.2  Opmerkingen  m.b.t.  AMH 

Op  basis  van  de  "User  Requirement  AMH"  en  "Automated  Message  Handler  System  Definition 
and  Specification"  kunnen  een  aantal  opmerkingen  worden  geplaatst  en  vragen  gesteld  worden 
over  zaken  die  niet  correct  zijn,  niet  duidelijk  zijn  of  ontbreken.  Dit  in  relatie  tot  de  gewenste 
(vereiste)  functionaliteit  van  een  geautomatiseerd  berichtenverweridngssysteem. 

In  algemene  zin  kan  opgemeikt  worden  dat  het  AMH  systeem  ontwikkeld  is  voor  een 
(gedistribueerde)  UNIX  omgeving  op  een  PC.  Bij  de  ontwikkeling  is  gebruik  gemaakt  van  de 
(voor  zeer  veel  omgevingen  beschikbare)  programmeertalen  Ada  en  C,  zodat  het  systeem  ook 
voor  andere  (niet-UNIX)  omgevingen  geschikt  kan  worden  gemaakt  door  de  ontwikkelaars. 
Daarbij  zouden  enkele  gebruikte  specifieke  UNIX  faciliteiten  echter  voor  problemen  en 
beperkingen  kunnen  zorgen. 

Voor  de  opslag  van  gegevens  is  bij  het  AMH/DEF  (berichtformaten)  gebruik  gemaakt  van  het 
Oracle  RDBMS.  Deze  software  is  in  vele  omgevingen  beschikbaar.  Voor  het  AMH/MFS  is  wel 
vermeld  dat  gebruik  wordt  gemaakt  van  SQL,  maar  niet  van  welke  DBMS  gebruik  is  gemaakt 
voor  de  opslag  van  operationele  gegevens.  Evenmin  is  vermeld  of  er  interfaces  zijn  voor 
vcrschillende  DBMSs.  Waarschijnlijk  is  er  bij  AMH/MFS  evenals  voor  AMH/DEF  gebruik 
gemaakt  van  het  Oracle  RDBMS. 
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AMH/DEF  en  AMH/MFS  worden  geleverd  als  uitvoerbare  programma’s.  Voor  AMH/MFS 
kunnen  voor  de  verschillende  onderdelen  (ADatP-3  MTF,  ACP 127,  /v.400)  applicatie 
bibliotheken  (eventueel  zonder  gebruikersinterface  modules)  worden  geleverd  in  de  vorm  van 
broncode  voor  package  specificaties  en  gecompileerde  code  voor  package  bodies. 

Specifieke  vragen  (onduidelijkheden)  m.b.t.  de  functionaliteit  van  AMH/DEF  zijn; 

•  Gebeurt  bet  laden  van  MTFs  afkomstig  van  de  Master  Development  Database  van 
ADSIA  inclusief  de  condities  voor  sets  en  velden? 

En  zo  ja,  zijn  de  condities  dan  in  bet  correcte  (voor  AMH  gescbikte)  formaat? 

Is  de  mogelijkbeid  om  condities  te  specificeren  voldoende  urn  alle  gevallen  af  te  dekken? 

•  Is  er  een  check  op  een  correcte  syntax  bij  bet  invoeren  en  wijzigen  van  een  conditie? 

•  Is  bet  mogelijk  om  bij  kolomsets  de  mogelijkbeid  om  uitlijning,  start  positie  en  lengte  in 
te  voeren? 

•  Is  bet  mogelijk  om  een  versie  van  een  bericbtformaat  te  selecteren  voor  distributie? 

•  Vindt  er  een  check  plaats  bij  bet  invoeren  van  parameters  voor  toegang  tot  een  database? 
Moet  de  operator  MTF  en  ODB  queries  (MERL  en  SQL  statements)  invoeren? 

Moet  dat  gebeuren  voor  elk  type  AMH/MFS,  die  een  beptalde  distributie  krijgen? 

Is  er  een  gebruikersvriendelijke  methode  om  database  parameters  in  te  voeren? 

•  Kunnen  ook  berichtformaten  met  een  andere  dan  de  ADatP-3  stnictuur  (syntax'!, 
gedefinieerd  worden? 

Kan  AMH/DEF  daarvoor  aangepast  worden? 

Specifieke  vragen  (onduidelijkheden)  m.b.t.  de  functionaliteit  van  AMH/MFS  zijn: 

•  Kan  bet  wijzigen  van  de  effectieve  datum  van  een  bericbtformaat  alleen  m.b.v.  een 
mission  file  gebeuren? 

•  Wordt  de  inhoud  van  een  veld  direkt  na  invoer  ervan  getest? 

Of  op  commando  na  volledige  (of  gedeeltelijke)  invoer  van  bet  bericht? 

•  Is  er  begeleiding  bij  bet  invoeren/prepareren  van  een  envelop  voor  een  communicatie 
systeem? 

•  Is  er  een  mogelijkbeid  om  MTF  en/of  ODB  queries  aan  te  passen? 

Of  is  dat  alleen  in  AMH/DEF  mogelijk? 
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•  Gebeurt  het  prepareren  van  de  heading  automatisch  voor  automatisch  samengestelde 
berichten? 

Of  door  de  verantwoordelijke  operator  bij  het  aanpassen  van  de  gegenereerde  tekst? 

•  Hoe  \vordt  omgegaan  (beheer)  met  de  verschiUende  versies  en  commentaren  van  het  staf 
personeel  bij  handmatige  preparatie  van  een  bericht? 

•  Is  er  ook  een  check  op  afhankelijkheden  (condities)  tussen  verschiUende  niveaus  van  een 
bericht? 

Bijvoorbeeld:  de  aanwezigheid  van  een  set  kan  afhangen  van  de  waarde  van  een  veld  in 
een  vorige  set. 

•  Is  er  een  globale  zoekactie  mogeUjk  voor  inkomende  of  uitgaande  berichten? 

Of  moet  specifiek  gezocht  worden  naar  berichten  met  een  bepaalde  status? 

•  Kan  AMH/MFS  ook  andere  niet-ADatP-3  berichten  met  een  andere  structuur  (syntax) 
venverken? 

Kan  AMH/MFS  daarvoor  aangepast  worden? 

Op  14  mei  1992  is  in  Brussel  een  demonstratie  van  de  AMH  (genaamd:  IRIS  for  UNIX)  gegeven, 
waarbij  is  aangetoond  dat  het  systeem  weikt.  Het  aantonen  van  de  weiking  is  gedaan  voor  een 
klein  aantal  ADatP-3  berichtformaten  en  berichten  in  een  omgevmg  waarbij  gebruik  is  gemaakt 
van  verschiUende  soorten  (typen,  merken)  commercieel  verkrijgbare  wetkstations. 

De  demonstratie  heeft  voor  het  grootste  deel  van  de  hiervoor  gestelde  vragen  geen  antwoord 
opgelevcrd,  zodat  de  antwoorden  nog  open  blijven.  Deze  vragen  zuUen  in  een  uitgebreide 
evaluatic  beantwoord  moeten  worden. 
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7.  Plaats  van  een  MHS  binnen  de  C^-filosofie  van 
deKL 

Er  zijn  een  aantal  documenten  beschikbaar  die  communicatie  stnicturen  voor  commandovoering 
binnen  de  NATO  beschrijven.  Achtercenvolgens  worden  bier  de  C^-filosofie  van  de  KL,  bet 
wericprogramma  van  bet  ATCCIS  project  en  bet  NATO  CIS  concept  bebandeld. 


7. 1  De  C2.filosofie  van  de  KL 

In  de  C^-filosofie  van  de  KL  [CVKL911  wordt  gesproken  over  gegevensverwerving  op  basis  van 
ADatP-3  en  een  MHS,  informatieverwerking  met  C^-systemen  en  gegevensdistributie  met  bebulp 
van  bet  ZODIAC  netweik  en  bet  CPCN  concept. 

De  organisatie  van  een  CPCN  zoals  aangeven  binnen  de  C^-filosofie  van  de  KL  is  weergegeven 
in  figuur  7.1.  In  de  praktijk  zal  de  samenstelling  en  de  omvang  van  een  CPCN  op  legercorps-, 
divisie-  respectievelijk  brigadeniveau  een  aantal  verscbillen  vertonen  maar  de  algemene  origntatie 
rond  een  LAN  blijft  steeds  een  uitgangspunt.  Standaardisatie  m.b.t.  OSI,  POSIX,  SQL  en  X- 
windows  biedt  een  goede  basis  voor  de  ontwikkeling  van  een  dergelijk  CPCN. 

De  functionaliteit  geboden  door  een  MHS,  bijvoorbeeld  door  de  AMH  van  Systematic,  valt  uiteen 
in  vier  belangrijke  componentcn  (zic  boofdstukken  5  en  6),  waarvan  er  drie  on-line  en  6dn  off-line 
zullen  worden  geimplementeerd.  De  operator  interface  wordt  bij  voorkeur  gereaUseerd  op 
modeme  workstations,  terwijl  de  I/O  functie  gerealiseerd  kan  worden  op  de  CFE  processor  en  de 
database  verweiiting  kan  worden  uitgevoerd  op  de  database  server.  Het  CPCN  zoals  aangegeven 
in  figuur  7.1  recbtsboven  geeft  dan  ook  een  beter  beeld  van  de  realiteit  geeft  dan  figuur  7.1 
linksboven.  Het  beste  wordt  de  structuur  van  een  CPCN  ecbter  bescbreven  a.d.b.v.  figuur  7.1 
recbtsonder  omdat  ook  de  CFE  en  de  database  server  over  bet  algemeen  bet  beste  gerealiseerd 
kunnen  worden  op  workstations. 
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Figuur  7.1:  De  organisatie  van  een  CommandoPost  Communicalie  Neiwerk. 


Voorlopig  gaal  men  er  vanuil  dat  men  met  een  MHS  en  ADatP-3  berichten  gaat  werken.  Het  is 
echter  niet  uitgesloten  dat  nieuwe  ontwikkelingen  binnen  het  ATCCIS  programma  (zie  volgende 
paragraaO  aanleiding  zullen  zijn  voor  een  reorganisatie  van  het  CPCN  waaibij  het  aandeel  van 
ADatP-3  berichten  sterk  zal  worden  gereduceerd.  De  bulk  van  de  informatie  zal  dan  m.b.v. 
ATCCIS  berichten  worden  overgedragen.  Een  MHS  dient  dan  ook  zo  flexibel  Gees  generiek  van 
opzet)  te  zijn  dat  t.z.t.  meerderc  berichtformaten  kunnen  worden  geaccepteerd. 

Omdat  de  AMH  van  Systematic  een  generiek  karakter  heeft,  d.w.z.  niet  alleen  in  combinatie  met 
ADaiP-3  en  ACP  127  maar  tot  op  zekere  hoogte  ook  in  combinatie  met  andere  standaards  te 
gebruiken  is,  zal  dit  systeem  gedurende  langere  tijd  een  belangrijke  rol  kunnen  spelen  in  de  C^- 
architectuur  van  de  KL. 
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12  Het  ATCCIS  Project 

Het  ATCCIS  werkprogramma  zoals  afgebeeld  in  figuur  7.2  is  er  op  gericht  om  bestaande  C^- 
produkten  Gees  berichten  die  woiden  gegenercerd  t.b.v.  de  commandovoering)  te  decomposeren, 
de  afzonderlijke  broksnikken  opnieuw  te  ordenen  en  nieuwe  C^-produkten  te  produceren.  De 
meesi  elementairc  delen  van  het  C^-produkt  zuUen  worden  gebruikt  bij  het  opstellen  van  een  data 
element  dictionary.  Daamaast  zal  er  worden  gewerkt  aan  een  informatie  model  voor  de  tactische 
commandovoering  binnen  de  landstrijdkrachten  van  de  NATO.  Dit  informatie  model  zal  samen 
met  de  data  element  dictionary  worden  gebruikt  bij  de  bouw  van  een  demortstratie  systeem. 


Figuur  7.2:  Het  ATCCIS  werkprogramma. 

Indien  het  ATCCIS  programma  slaagt,  dan  zal  de  interoperabiliteit  sterk  verbeteren.  Voor 
interoperabilitcit  is  namelijk  nict  allcen  een  gcmeenschappclijke  communicatie  van  belang  maar 
ook  cen  gemeenschappelijk  begrip  van  de  informatie  die  wordt  overgedragen. 
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7.3  Het  NATO  CIS  Concept 

Dan  is  er  vervolgens  het  werit  van  NACISA  ([NACISA89],  [NACISA90])  waarin  de  architectuur 
van  het  geplande  NATO  C^-communicatie  subsysteem  wordt  beschreven.  Binnen  dit  programma 
spelen  de  volgende  drie  C^-systemen  een  belangrijke  rol: 

•  ACCS  (Air  Command  and  Control  System). 

•  BICES  (Battlefield  Infonnation  Collection  and  Exploitation  System). 

•  NMOS  (NATO  Maritime  Operations  intelligent  support  Systems). 

Zoals  figuur  7.3  laat  zien  gaat  het  bij  de  opzet  van  dit  strategische  netwerk  voomamelijk  om  een 
integratie  van  een  aantal  nationale  netwerken  tot  een  geheel.  De  structuur  is  gebaseerd  op 
(breedband)  ISDN  technologic. 


Figuur  7.3: 


De  architectuur  van  het  NATO  C^-Communicatic  Subsysteem. 
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Deze  opzet  is  onlangs  overgenomen  binnen  het  Tri-MNC  CIS  Concept  ([SHAPE91], 
(NACISC91]).  Een  nuttig  concept  dat  er  aan  ten  grondslag  ligt  is  de  tweedeling  tussen  het 
gebruikersdomein  en  het  transportdomein.  Bini^n  het  gebniikersdomein  zijn  een  aantal  functies 
gedefinieerd; 

•  Informatieverwerkende  systemen,  zoals:  een  Mens  Machine  Interface  (MMI),  een 
Database  Management  Systeem  (DMBS),  een  Operating  Systeem  (OS), 
datacommunicatie  faciliteiten,  beslissingsondersteunende  systemen  en  trainers. 

•  Teleservice  functies:  telefoon,  telegrafie,  fax  en  video. 

•  Gateway  en  distributie  functies. 

•  Controie  en  management  functies. 

Binnen  het  transportdomein  zijn  alle  functies  gedefinieerd  die  nodig  zijn  om  verschillende 
gebruikersdomeinen  met  elkaar  te  verbinden.  Men  maakt  ii.erbij  onderscheid  tussen  een  algemeen 
transport  segment  en  een  special  purpose  transport  segment.  Het  algemene  segment  is  in 
figuur7.3.  aangeven  m.b.v.  een  referentie  punt  en  zal  bestaan  uit  systemen  zoals  NAFIN 
(Netherlands  Armed  Forces  Integrated  Network),  publieke  PTf  netwerken,  SATCOM  netwerken, 
etc.  Het  special  purpose  segment  is  o.a.  bedoeld  voor  het  uitvoeren  van  nucleaire  taken  en  de 
aansluiting  van  mobiele  eenhedeii  op  het  algemene  segment. 

Om  de  intcroperabiliteit  tussen  de  verschillende  systemen  te  verbeteren  wordt  gesj,  •okei.  over 
standaardisatie  m.b.t.  ACP-127  en  ADatP-3.  Alle  gebruikers  zouden  toegang  krijgen  tot  een 
telefoon  service  en  een  MHS  ondcrsteund  op  een  PC  platform.  Specifieke  gebruikers  d’>  gebruik 
maken  van  een  multifunctioneel  werkstation  krijgen  toegang  tot  de  MIS/ACCIS  databases, 
beschikken  over  een  MHS  op  basis  van  geformatteerde  berichten  ( \DatP-3)  en  maken  gebruik 
van  alle  teleservices.  Naast  datacommunicatie  faciliteiten  krijgen  sommige  gebruikers  ook  de 
mogelijkheid  om  grafisclie  informatie  uit  te  wisselen. 

Als  men  de  indeling  van  NAQSA  zou  hanteren  m.b.t.  C^-systemen  voor  de  KL  dan  moet  men 
constateren  dat  het  gehele  CPCN  behoort  tot  het  gebruikersdomein  en  het  LK  VBD  stelsel 
opgebouwd  rond  het  ZODIAC  netwerk  voimt  in  feite  een  special  purpose  segment  binnen  het 
transportdomein. 
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8.  Conclusies  en  aanbevelingen 

FORMETS,  zoals  beschreven  in  ADatP-3,  is  momenteel  hei  enige  geaccepteerde  systeem  voor  de 

produktie  van  geformatteerde  berichten  binnen  de  NATO  en  zal  worden  toegepast  binnen  de 

commandovoeringssystemen  van  de  landstrijdkrachten  van  de  NATO. 

Het  werken  met  ADatP-3  heeft  voor-  en  nadelen. 

Voordelen  van  ADatP-3  zijn: 

•  Slandaardisatie  op  een  eenduidig  berichtformaat  binnen  de  NATO. 

•  De  berichtformaten  zijn  automatisch  verwerkbaar. 

Aulomatische  verwerking  van  een  artificiele  taal  is  efficienter  dan  van  een  natuurlijke 
taal. 

•  De  berichtformaten  zijn  ook  bruikbaar  zonder  ADP  support. 

Nadelen  van  ADatP-3  zijn: 

•  Het  ontbreekt  ADatP-3  op  dit  moment  aan  voldoende  middelen  om  de  semantiek  van  de 
berichten  op  een  eenduidige  manier  te  kuimen  beschrijven. 

•  Er  is  een  zekere  inconsistentie  tussen  een  aantal  berichtformaten  wegens  het  ontbreken 
van  een  gemeenschappelijk  conceptueel  model. 

•  De  betekenis  van  elementairc  gegevens  is  niet  op  een  consistente  manier  gedefinieerd.  Dit 
is  ook  vanwege  het  ontbreken  van  een  gemeenschappelijk  conceptueel  model. 

•  ADatP-3  is  omvangrijk. 

•  De  berichtformaten  zijn  moeilijk  te  doorgronden  zonder  ADP  support.  Het  aantal  bericht¬ 
formaten  is  omvangriik  en  de  structuur  van  de  berichtformaten  is  vaak  complex. 

•  ADatP-3  is  geschikt  gcmaakt  voor  geautomatiseerde  verwerking,  echter  niet 
geoptimaliseerd: 

Automatisch  verwerken  (doorgronden)  van  grote  stukken  ongestructureerde  tekst 
is  niet  of  met  veel  mociie  mogelijk. 

Conditionele  verwerking  is  nog  niet  gefoimaliseerd. 

De  structuur  van  berichten  (onderdelen)  sluit  niet  altijd  goed  aan  bij  de  structuur 
van  een  (relationclc)  database. 

Veldconvcrsics  zijn  niet  altijd  triviaal. 
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Beperkingen  vanuit  communicatie  medium,  zoals  maximale  regellengte  van  69 
karakters  (telex). 

•  Acceptatie  door  de  operationele  gebruiker  is  niet  altijd  even  goed. 

De  indruk  bestaat  dat  niet  iedereen  doordrongen  is  van  het  nut  van  een 
standaardisatie  van  de  berichtgeving. 

Vanuit  de  operationele  gemeenschap  bestaat  de  indruk  dat  zij  nauwelijks  invloed 
heeft  op  de  ontwikkeling  van  deze  standaards. 

De  standaards  worden  lang  niet  altijd  als  gebmikersvriendelijk  ervaren. 

De  problemen  van  ADatP-3  zijn  niet  onoverkomelijk.  In  het  kader  van  het  "ADSIA/NUNN 
initiatief '  zijn  met  betrekking  tot  "NATO  Procedural  Interoperability  Standards"  (NPIS)  projecten 
opgestart,  die  de  problemen  m.b.t.  de  defmitie  en  het  beheer  van  (elementen  van)  berichtfonnaten 
moeten  verminderen.  Systemen  met  geautomatiseerde  ondersteuning  kunnen  ook  goede 
mogelijkheden  bieden  voor  berichtenverwerking,  maar  deze  systemen  worden  dan  echter  wel 
complexer.  Hot  belangrijkste  is  dat  er  een  standaard  is  voor  geautomatiseerde  verwerking  van 
berichtcn. 

Er  kan  niet  gezegd  worden  dat  EDIFACT  (de  civiele  standaard)  te  verkiezen  is  boven  ADatP-3, 
omdat  EDIFACT  behalve  een  aantal  voordelen  ook  nadelen  kent  in  vergelijking  met  ADatP-3. 

Binncn  een  MHS  zijn  vicr  hoofdfuncties  te  onderscheiden:  de  berichten  I/O,  de  operator  interface, 
de  database  verwerking  en  het  beheer  van  de  lokale  berichtformaten.  Volledig  automatische 
verwerking  met  een  interface  naar  de  operationele  database  is  een  relatief  nieuwe  ontwikkeling  en 
zal  zich  in  een  nieuwe  generatie  van  C^-systemen  gaan  manifesteren. 

Bij  automatische  verwerking  van  (ADatP-3)  berichten  in  een  operationele  database  en  de 
preparatie  van  berichten  a.d.h.v.  de  informatie  die  ligt  opgeslagen  in  een  operationele  database 
kunnen  een  aantal  problemen  optreden; 

1)  Niet  triviale  veldconversies. 

2)  Het  niet  in  het  bericht  en/of  database  voorkomen  van  noodzakelijke  waarden. 

3)  Het  niet  good  aansluitcn  van  bericht-  en  databasestructuren. 

4)  Conflictcn  bij  tcgcnstrijdigc  en  gedateerde  berichtgeving. 
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Er  zijn  een  aantal  systemen  ontwikkeld  die  ondersteuning  bieden  bij  de  (automatische) 
verwerking  van  berichten.  Een  tweetal  systemen,  JAMPS  en  IRIS,  is  in  bet  kader  van  bet  project 
onderzocbt.  Beide  produkten  zijn  bescbikbaar  op  een  PC  en  omvatten  momenteel  aUeen  de 
functionaliteit  m.b.t.  de  preparatie  van  bericbten  en  bebben  geen  interface  met  een  operationele 
database. 

De  in  ontwikkeling  zijnde  AMH,  waarvan  de  werking  tijdens  een  demonstratie  is  aangetoond,  kan 
bruikbaar  zijn  voor  de  KL  bij  bet  realiseren  van  bun  CPCN.  Is  bet  niet  bet  complete  kant  en  klare 
systeem,  dan  wel  de  applicatie  bibliotbeken,  die  de  bouwstenen  voor  de  AMH  of  een  eigen  te 
ontwikkelen  bericbtenverwerkingssysteem  bevatten. 

Een  uitgcbreide  evaluatie  van  de  AMH  zal  moeten  volgen  om  de  exacte  bruikbaarbeid  aantonen. 

Standaardisatie  m.b.t.  ADatP-3,  OSI,  POSIX,  SQL  en  X-Windows  biedt  een  goede  basis  voor  de 
ontwikkeling  van  een  dergelijk  CPCN.  Duidebjk  is  dat  de  vier  boofdfuncties  van  een  MHS  op 
verscbillende  werkstations  kuiuien  en  zullen  worden  geimplementeerd. 

AdatP-3  en  bericbtenverwerkingssystemen,  zoals  de  AMH  van  Systematic,  zullen  ook  in  de 
periode  na  1995  nog  een  belangrijk  element  zijn  binnen  een  tactiscb  netweik  voor  de 
landstrijdkracbten. 

Informatie  overdraclit  op  bet  niveau  van  geformatteerde  bericbten  zou  in  de  komende  jaren  ecbter 
plaats  kunncn  gaan  maken  voor  informatie  overdracbt  tussen  de  operationele  databases  van 
diverse  C^-systemen.  Dit  is  dan  te  danken  aan  bet  ATCCIS  programma. 

Binnen  bet  C^-filosofie  van  de  KL  zou  men,  in  navolging  van  bet  Tri-MNC  CIS  concept,  een 
tweedeling  tussen  een  gebruikersdomein  en  een  transportdomein  kunnen  aanbrengen. 
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Afkoitingen 


ABDIS  Automatisch  BerichtenDIStributiesysteem 

ACCIS  Allied  Command  and  Control  Information  System 

ACCS  Air  Command  and  Control  System 

ACE  Allied  Central  Europe 

ACP  Allied  Communication  Publication 

ADatP-3  Allied  Data  Publication  3 


AMH  Automated  Message  Handler 

AMHS  Automated  Message  Handling  System 

ASCII  American  Standard  Code  for  Information  Interchange 

ATCCIS  Anmy  Tactical  Command  and  Control  System 
BERDIS  BERichtenDIStributiesysteem 

BICES  Battlefield  Infotmation  Collection  and  Exploitation  System 

B  VT  Beoordeling  Van  de  Toestand 

C^  Command  &  Control 

C^  Command,  Control  &  Communication 

C^I  Command,  Control,  Communication  &  Information  /  Intelligence 

CAX  Computer  Assisted  eXersize 

CClS  Command,  Control  &  Information  System 

CCITT  Intemation?!  Consultative  Comittee  for  Telephone  and  Telegraph 

CFE  Communication  Front  End 

CIS  Communication  and  Information  Systems 

CPCN  CommandoPost  Communicatie  Netwerk 

CVKL  CommandoVetbindingen  Koninklijke  Landmacht 

DCAWACO  DienstenCentnim  Automatisering  Wapen-  en  commandosystemen 

DST  Decision  Support  Tools 

EDI  Electronic  Data  Interchange 

EDIFACT  Electronic  Data  Interchange  For  Administration,  Commerce  and  Transport 

ESM  Electronic  Support  Measures 

FEL  Fysisch  en  Elektronisch  Laboratorium 

GOS  Gemenebest  van  Onafhankelijke  Staten 

GPS  General  Purpose  Segment 

HDLC  High  level  Data  Link  Control 


TNO-rapport 


Pagina 

73 


IDN 

ISDN 

ISO 

JAMPS 

JINTACCS 

JMAPS 

KL 

LACS 

LACS-C 

LACS-D 

LAN 

LK 

LKBP 

MISDN 

MMR 

MNC 

MT 

MTF 

NAFIN 

NMOS 

NPIS 

OSI 

PTT 

SHAPE 

SPS 

SQL 

STC 

TNO 

VBD 

WACS 

WAN 

WP 

ZODIAC 


Integrated  Digital  Network 

Integrated  Services  Digital  Network 

International  Organisation  for  Standardization 

JINTACCS  Automated  Message  Preparation  System 

Joint  Interoperability  of  Tactical  Command  and  Control  Systems 

Joint  Message  Analysis  and  Processing  System 

Koninklijke  Landmacht 

Local  Area  Communication  Subsystem 

Local  Area  Communication  Subsystem  with  Centralized  Resources 
Local  Area  Communication  Subsystem  with  Disuibuted  Resources 
Local  Area  Network 
Legerkorps 

Legerkorps  Berichten  Protocol 

Military  Integrated  Services  Digital  Network 

Minimal  Military  Requirement 

Major  NATO  Commander 

Militaire  Taakstelling 

Message  Text  Format 

Netherlands  Armed  Forces  Integrated  Network 

NATO  Marilin. '  Operations  intelligent  support  System 

NATO  Procedural  Interoperability  Standard 

Open  Systems  Interconnection 

Post,  Telefonie  en  Telegrafie 

Supreme  Headquarters  Allied  Powers  Europe 

Special  Purpose  Segment 

Structured  Query  Language 

SHAPE  Technical  Centre 

Organisatie  voor  Toegepast  Natuurwetenschappelijk  Onderzoek 
VerBindingsDieitst 

Wide  Area  Communication  Subsystems 
Wide  Area  Network 
Warshaw  Pact 

zone,  DIgitaal,  Automatisch,  Cryptografisch  beveiligd  legerkorpsrayon- 
verbinding,''''ysteem 
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